<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-us">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="DC.Language" scheme="rfc1766" content="en-us" />
<meta name="IBM.Country" content="ZZ" />
<!-- Licensed Materials Property of IBM                      -->
<!-- US Government Users Restricted Rights                   -->
<!-- Use, duplication or disclosure restricted by            -->
<!-- GSA ADP Schedule Contract with IBM Corp.                -->
<meta name="DC.Date" scheme="iso8601" content="2013-05-15" />
<meta name="copyright" content="&copy; Copyright IBM Corporation 2002, 2013" />
<meta name="security" content="IBM Confidential" />
<meta name="Robots" content="index,follow"/>
<meta name="keywords" content="who should read this document, who should read, document, this, read this document, who should" />
<meta name="keywords" content="how this document is organized, how organized, how to use this document, use this document, how to, how to use, conventions and terminology in" />
<meta name="keywords" content="terminology used in this document, conventions used in this document, migration, definition of, exploitation, coexistence, fallback, before installing" />
<meta name="keywords" content="actions to perform, meaning of, migration actions to perform, before first IPL, after first IPL, description, when change was introduced" />
<meta name="keywords" content="required action, target system hardware requirements, target system software requirements, other system (coexistence or fallback) requirements" />
<meta name="keywords" content="restrictions, system impacts, IBM Health Checker related check, steps to take, reference information, documents, related, publications, books" />
<meta name="keywords" content="related documentation, for z/OS publications, URL, Internet address, web address, installation steps, migration steps, steps for migration" />
<meta name="keywords" content="Enhanced PSP Tool, EPSPT, FIXCAT, REPORT MISSINGFIX, migration health checks, health checks, checks, migration health, IBM z/OS Management Facility" />
<meta name="keywords" content="Management Facility, IBM z/OS, z/OS Management Facility, IBM, z/OSMF, none, elements and features with, migration actions, Alternate Library for REXX" />
<meta name="keywords" content="no migration actions for, BDT, BDT File-to-File, BDT SNA NJE, BookManager READ, Communications Server Security Level 3, EREP, ESCON Director Support" />
<meta name="keywords" content="FFST, GDDM, GDDM-PGF, GDDM-REXX, HCD, HCM, HLASM Toolkit, ICKDSF, Integrated Security Services, Metal C Runtime Library, MICR/OCR, NFS" />
<meta name="keywords" content="Run-Time Library Extensions, SMP/E, TIOC, TSO/E, z/OS IBM TDS, z/OS Security Level 3, 3270 PC File Transfer Program, general, for everyone" />
<meta name="keywords" content="general migration actions, everyone, migration actions for, preinstallation migration actions, reviewing, PSP bucket, upgrade IDs, for PSP buckets" />
<meta name="keywords" content="maintenance, coexistence and fallback, zSoftware Migfration Capacity Planning Aid (zSoftCap), zSoftCap, capacity evaluation with zSoftCap" />
<meta name="keywords" content="CPU evaluation with zSoftCap, evaluation with zSoftCap, storage, for zSoftCap, z/OS root size, root size, z/OS, DASD for z/OS root, XCF groups" />
<meta name="keywords" content="CustomPak Installation Dialog, IFAPRDxx product IDe, first IPL, migration actions before, IPL, migration actions before first" />
<meta name="keywords" content="pre-IPL migration actions, IPCS, setting up, used by IPCS, parmlib, SYS1.PARMLIB, using shipped members of, proclib, SYS1.PROCLIB, /etc directory" />
<meta name="keywords" content="migrating files in, /var directory, messages, updating automation for changed, examining, user modifications, modifications, user, usermods" />
<meta name="keywords" content="SVC routines, migrating, exit routines, user exits, ISV products, reconnecting, for ISVs, subsystems, procedures, updating operational" />
<meta name="keywords" content="defining new profiles, FACILITY class, RACF, verifying limits, virtual storage, setting virtual limits, determining virtual storage with" />
<meta name="keywords" content="MEMLIMIT parameter, for flashes, backing, backing virtual, updating, deleted data sets and paths, removed data sets and paths, deleted, data sets" />
<meta name="keywords" content="paths, new data sets, new, PDSE sharing restrictions, sharing restrictions, PDSE, MAXUSER, hardware migration actions, hardware, compatibility changes" />
<meta name="keywords" content="zEC12 server, migrating to, software support features, server, zEC12, migrating to zEC12, processors, z196 server, zEnterprise, migrating to z196" />
<meta name="keywords" content="z196, z114 server, migrating to z114, z114, SMP/E REPORT MISSINGFIX, Fix Category, HOLDDATA, z10 server, z10, migrating to z10" />
<meta name="keywords" content="software support of z10, features, software support of servers, coexistence requirements, for Enhanced PSP Tool, ARCH(8) compiler option" />
<meta name="keywords" content="TUNE(8) compiler option, HiperDispatch, Capacity Provisioning, large page support, InfiniBand, Parallel Sysplex InfiniBand" />
<meta name="keywords" content="PSIFB (Parallel Sysplex InfiniBand), hardware no longer supported, unsupported devices, removing, removing unsupported, devices, attaching new" />
<meta name="keywords" content="relieving virtual storage constraint with, link pack area (LPA), LPA (link pack area), coupling facility control code (CFCC) levels, levels" />
<meta name="keywords" content="CFCC (coupling facility control code), CFRM policy, for CFSizer tool, for CFCC levels and processors, sysplex, sysplex migration actions" />
<meta name="keywords" content="Parallel Sysplex migration actions, migration actions after, migration actions after first, post-IPL migration actions, BCP, dump data sets" />
<meta name="keywords" content="stand-alone, stand-alone dump data sets, BCP migration actions, Generic Tracker, BCPii API calls, BCPii ENF exits, IOSSPOF macro" />
<meta name="keywords" content="EEPLEVENTSPECIFICINFO in control block IXLYEEPL, PGSER PROTECT/UNPROTECT, large pages, IEASYSxx, WARNUND, IPL text, creating, stand-alone dump" />
<meta name="keywords" content="reassembling, dump, reassembling stand-alone, one-step JCL, one-stage JCL, IBM Health Checker, automatic start-up, CPUs, maximum number supported" />
<meta name="keywords" content="Downgrade the SYSDSN ENQ, message automation, address space, PCIE, PCI Express, Unicode Services, linkage conventions, &lt;bogus index entry&gt;, ESQA" />
<meta name="keywords" content="memory pool, Flash Express, Auto-reply for WTORs, TRACKDIRLOAD, SETLOAD IEASYM, CPCC, Windows-based, Capacity Provisioning Control Center" />
<meta name="keywords" content="BookManager BUILD, support for, Communications Server, Communications Server migration actions" />
<meta name="keywords" content="IBM Configuration Assistant for z/OS Communications Server, AUTHCMD and AUTHPGM NAMES section of your IKJTSOxx member, IPv6, DVIPSEC parameter" />
<meta name="keywords" content="IPSEC statement, TCP/IP profile, IP fragment, IP Fragment attack type, Intrusion Detection Services, FTP password and Communication Server" />
<meta name="keywords" content="NMI applications, 64-bit TMI copy buffer function, GetProfile request of the TCP/IP callable network management interface (NMI)" />
<meta name="keywords" content="IPv6 support for policy-based routing, GATEWAY statements replaced by BEGINROUTES statements, BIND 9.2.0, BIND 9.2.0 name server, ICLI component" />
<meta name="keywords" content="ICSF and NSS daemon, IKE daemon, Communications server, AT-TLS access to CSFIQA and CSFRNG resources, before the first IPL, TCPIP, D TCPIP, tnproc" />
<meta name="keywords" content="&lt;Telnet&gt;, CONN command, automation, resolver address space initialization, resolver, OMROUTE, OMPROUTE_OPTIONS, environment variable, OMPROUTE" />
<meta name="keywords" content="TCP related configuration statements, Netstat enhancementss, Netstat enhancements, Cryptographic Services, ICSF migration actions" />
<meta name="keywords" content="OCSF migration actions, Cryptographic Services migration actions, OCSF directory migration, OCSF profiles" />
<meta name="keywords" content="use of ICSF when running FIPS 140-2 mode applications, FIPS 140-2 mode, System SSL migration action, System SSL" />
<meta name="keywords" content="ensuring ICSF is available when running System SSL in FIPS mode" />
<meta name="keywords" content="ensuring all RACF user IDs that start SSL applications in non-FIPS mode can access the CSFRNG resource of the CSFSERV class, DFSMS" />
<meta name="keywords" content="DFSMS migration actions, SMS control data sets, control data sets, migrating SMS, data integrity of SMS control data sets" />
<meta name="keywords" content="integrity of SMS control data sets, source control data set (SCDS), ensuring integrity of, SCDS (source control data set)" />
<meta name="keywords" content="ACDS (active control data set), active control data set (ACDS), COMMDS (common communications data set), common communications data set (COMMDS)" />
<meta name="keywords" content="Open/Close/End of Volume ABEND messages, SMA fields from the SMS storage group construct IGDSGD" />
<meta name="keywords" content="removing SMA fields from the SMS storage group construct IGDSGD, dynamic link libraries with Language Environment" />
<meta name="keywords" content="DLLs (dynamic link libraries) with Language Environment, 3800 Printing Subsystem, preparing to use, 3900 Printing Subsystem, SYS1.IMAGELIB" />
<meta name="keywords" content="IEBCOPY utility, examining and updating program calls to, DFSMSdfp IEBCOPY, core image of DFSMSdss Stand-Alone Services, building" />
<meta name="keywords" content="Stand-Alone Services, building core image of DFSMSdss, applications that depend on the LIST DUMPCLASS command, DFSMShsm, LIST DUMPCLASS command" />
<meta name="keywords" content="RACF tape profile processing, OAM DB2 BIND jobs, BIND jobs, OAM DB2, DB2 BIND jobs, OAM, SMS volume selection" />
<meta name="keywords" content="new default behavior for full-volume and track restore with VTOC, default change for restore, VTOC track, changes to CDC records" />
<meta name="keywords" content="backup data set name format, migrated data sets, DFSORT, DFSORT migration actions, DFSORT TUNE=OLD, TUNE=OLD, defaults DFSORT" />
<meta name="keywords" content="DFSORT EXPOLD=MAX and EXPRES=0, EXPOLD=OLD, EXPRES=0 DFSORT, Distributed File Service, Distributed File Service migration actions, clone function, zFS" />
<meta name="keywords" content="zFS clone function, ioeagfmt (zFS batch utility), Infoprint Server, Infoprint Server migration actions, installing, Upgrade Java for Infoprint Server" />
<meta name="keywords" content="JES2 migration actions, JES2, JES, JESJOBS access profiles, authority, SSI 85, Job Modify SSI 85, BRODCAST parameter, OUTDEF statement" />
<meta name="keywords" content="JCLERR parameter, JOBDEF statement, JES3, JES3 migration actions, JES3 release level format, JES3 release format, SSI 54, SSI 82, SSI 83" />
<meta name="keywords" content="Library Server, Library Server migration actions, notes files, Library Server InfoCenters, RMF, RMF migration actions, ERB2XDGS, ERB3XDRS" />
<meta name="keywords" content="RMF Monitor III Sysplex Data Retrieval services, RMF Monitor II Sysplex Data Gathering services" />
<meta name="keywords" content="GPMSERVE and GPM4CIM options for TCP/IP address regular expressions, RACF and GPMSERVE Started Task" />
<meta name="keywords" content="Define the RACF definitions to enable the GPMSERVE Started Task for Authorization Code zero (AC=0), Monitor III version, using correct, ZFS" />
<meta name="keywords" content="RMF data gathering option, NOZFS, SMF 74.9 data collection, SDSF, SDSF migration actions, ISFPARMS, console name modification, extended console name" />
<meta name="keywords" content="Security Server, Security Server migration actions, RACF migration actions, class name conflicts, duplicate class names, router table" />
<meta name="keywords" content="class descriptor table (CDT) names, CDT (class descriptor table) names, CHOWN.UNRESTRICTED profile in the RACF UNIXPRIV class" />
<meta name="keywords" content="distributed identify filter, identity propagation, normalization of RACF user names, database templates, updating RACF, RACF database templates" />
<meta name="keywords" content="IRRMIN00 utility, C/C++, XL C/C++, XL C/C++ migration actions, z/OS Font Collection, using IBM fonts, fonts, after the first IPL, z/OS UNIX" />
<meta name="keywords" content="HFS to zFS, migrating file system from, migrating from HFS to, sysplex root from HFS to zFS, z/OS UNIX migration actions, JVM applications, accept" />
<meta name="keywords" content="IOEFSPRM configuration file, support added, zlsof shell command, SMF type 92 subtype 11 close records, sticky bit files, BPX.UNIQUE.USER profile" />
<meta name="keywords" content="BPX.DEFAULT.USER profile replaced by BPX.UNIQUE.USER, PGSER, DASD, Predictive Failure Analysis (PFA), storage requirements, DASD requirements, INIT" />
<meta name="keywords" content="DEFAULT, HARDCOPY and CONSOLE keyword statements require blank delimiter., CONSOLxx, S99DSABA, S99ACUCB, S99DSABA and S99ACUCB, flags" />
<meta name="keywords" content="TIOT and XTIOT limits, XCF/XES, restart, library lookaside (LLA), CSVLLAxx member, discontinue use, MTFTPS" />
<meta name="keywords" content="problem documentation upload utility (PDUU), CMDS ABEND command, CMDS FORCE command, CON=, default changes, HIPERDISPATCH=YES, default" />
<meta name="keywords" content="IEAOPTxx keyword, COMMNDxx, Runtime Diagnostics, start, HZR address space, problem management, OPERLOG EMCS console name change, default change" />
<meta name="keywords" content="CLEANUP_TIMEOUT, CLEANUP_TIMEOUT parameter of the automatic restart management (ARM), directory setting, PFA (Predictive Failure Analysis)" />
<meta name="keywords" content="AIRSHREP.sh, console commands and problem determination, problem determination and console commands, ALLOWCMD(Y) keyword, GRS" />
<meta name="keywords" content="Runtime Diagnostics and PFA, PFA, AUTHQLVL parameter, GRSCNFxx parmlib member, qnames, Provisioning Manager, CIM Client for Java Version 2" />
<meta name="keywords" content="SNMP sysObjectID MIB object, sysObjectID MIB object, SNMP, MIB object, SNMP sysObjectID, OSNMPD.DATA file, SNMP sysObjectID MIB object in" />
<meta name="keywords" content="Before installing, FTP daemon console messages, FTP, User ID for the resolver, define, QDIO inbound workload queueing for EE traffic" />
<meta name="keywords" content="workload queueing function for EE traffic, Enterprise Extender (EE) traffic and QDIO inbound workload queueing, ancillary input queue (AIQ), FIPS mode" />
<meta name="keywords" content="ICSF, CSFPDVK and CSFPDMK, Intrusion Detection Services and traffic monitoring, traffic monitoring, attack detection, scan detection, FTCHKPWD" />
<meta name="keywords" content="FTP user exit routine FTCHKPWD, FTCHKPWD exit routine, additional parameter, password or password phrase, VIPARANGE processing, understand" />
<meta name="keywords" content="DSPNAME for TCP/IP, IPCONFIG and IPCONFIG6, IVTCSM ASSIGN_BUFFER requests, CSM buffer, reason code 26, CSA shortage, DSPNAME and VTAM" />
<meta name="keywords" content="VIPARANGE definitions, review, VTAM internal trace, TRACE command, VTAM start list, ICSF migration action" />
<meta name="keywords" content="ensuring that the CSFPUTIL utility is not used to initialize a PKDS, CSFIQA resource of the CSFSERV class" />
<meta name="keywords" content="RACF user ids and CSFIQA resource of the CSFSERV class, ICSF master keys, master keys, migration action for" />
<meta name="keywords" content="removal of NOIMBED and NOREPLICAT from output, LISTCAT, IGGCATxx, update operator procedures for, IGGPRE00, IGGPOST0, DADSM pre- and post-processing" />
<meta name="keywords" content="IEBCOPY update, Catalog Search Interface (CSI), CSI (Catalog Search Interface), at startup, PDA trace, data set recovery, fast replication, using" />
<meta name="keywords" content="FlashCopy, FRRECOV, DATASETRECOVERY, SETSYS FASTREPLICATION, DATASETRECOVERY parameter, tuning, ARC1809I" />
<meta name="keywords" content="patch disabling unwanted ARC1809I messages (DFSMShsm), removal of, VOLUMEPAIRMESSAGES, ARC0036I (E), ARC0503I (E), ARC0704I (E), ARC0036, changed type" />
<meta name="keywords" content="ARC0503, ARC0704, DFSMShsm: Removal of the patch preventing the SMS MVT chain rebuild" />
<meta name="keywords" content="Removal of the patch preventing the SMS MVT chain rebuild (DFSMShsm), patch preventing the SMS MVT chain rebuild (DFSMShsm)" />
<meta name="keywords" content="preventing the SMS MVT chain rebuild (DFSMShsm), removal of patch, SMS MVT chain rebuild (DFSMShsm), removal of patch preventing" />
<meta name="keywords" content="MVT (SMS) chain rebuild (DFSMShsm), chain rebuild (DFSMShsm), removal of patch preventing SMS MVT, rebuild of chain (DFSMShsm), resource contention" />
<meta name="keywords" content="ARCCAT, CDS backup, when starting CDS backup, ARRCAT, migration job for DFSMSdfp OAM., CBRSMR1D, OAM configuration database migration job (CBRSMR1D)" />
<meta name="keywords" content="DFSMSdfp OAM., DFSMS macros, 64-bit mode, AR mode, COPYVOLID, DFSMSdss, zFS storage requirements, IOEFSPRM, zfsspace utility, .bak file system" />
<meta name="keywords" content="zFS cloning support, zFS multi-file system aggregates, zFS compatibility mode aggregates, DFS client (DFSCM), DCE/DFS, sysplex=filesys" />
<meta name="keywords" content="shared file system, IP PrintWay migration from basic mode to extended mode, basic mode to extended mode, IP PrintWay migration from, extended mode" />
<meta name="keywords" content="IP PrintWay migration from basic mode to, printer inventory, region size change, IEFUSI, aopsetup, running, z11 mode, JES3 DLOG, DLOG, DATLOREC" />
<meta name="keywords" content="DATINPTR (IATYDAT), *S main, FLUSH, Automatic flush, IAT3100, Messages, Language Environment, CICS system definition file for Language Environment" />
<meta name="keywords" content="CSD (CICS system definition) file for Language Environment, Language Environment load modules in, CEERDOPT sample, CEERCOPT sample, CELQRDOP sample" />
<meta name="keywords" content="runtime options report, for Language Environment options, CEEPRMxx parmlib, Language Environment migration actions, ERB812I, ERB813I" />
<meta name="keywords" content="SMF 72.5 data collection, WebSphere MQ with SDSF, sysplex-wide data on SDSF panels, OPERLOG panel, devices on the SDSF PUN panel" />
<meta name="keywords" content="devices on the SDSF RDR panel, SDSF custom properties, /usr/sbin/mount invocations, /usr/sbin/unmount invocations, migration action, Process Manager" />
<meta name="keywords" content="Connection Manager, z/OS UNIX System Services Connection Scaling, symbolic links for cron, mail, and uucp utilities, invalid REXX variables" />
<meta name="keywords" content="assistive technologies, navigation, keyboard, user interface, ISPF, shortcut keys, PF keys, accessibility, screen readers, Notices" />
<title>Migration from z/OS V1R13 and z/OS V1R12 to z/OS V2R1</title>
<link rel="stylesheet" type="text/css" href="ibmidwb.css" />
</head>
<body role="main">
<a id="Top_Of_Page"></a><h1>z/OS</h1>
<h1>Migration from z/OS V1R13 and z/OS V1R12 to z/OS V2R1</h1><span class="productlevel">Version 2</span> 
<br />
<div id="e0z3m100-gen1">
<div class="pblklblbox">
<span class="pblktitle">&nbsp;</span>
<p>
<h1 id="wq2">Note:</h1>
<p>Before using this information and the product it supports, be sure
to read the general information under <a href="e0z3m100.htm#notice">Notices</a>.</p></p></div></div>
<div id="e0z3m100-gen2">
<span class="ednoticestitle"></span>
<p>This edition applies to version 2 release 1 modification 0 of IBM z/OS (product
number 5650-ZOS) and to all subsequent releases and modifications
until otherwise indicated in new editions.</p>
<p>When you send information to IBM, you
grant IBM a nonexclusive right to use or distribute
the information in any way it believes appropriate without incurring
any obligation to you.</p></div><div><strong>Copyright International Business Machines Corporation 2002, 2013.</strong><br />US Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.</div>

<div id="wq3">
<h1>Contents</h1>
<div class="head1"><a id="ToC_2" href="e0z3m100.htm#wq4" class="toclink">Figures</a></div>
<div class="head1"><a id="ToC_3" href="e0z3m100.htm#wq5" class="toclink">Tables</a></div>
<div class="head1"><a id="ToC_4" href="e0z3m100.htm#about" class="toclink">About this document</a></div>
<div class="head2"><a id="ToC_5" href="e0z3m100.htm#e0z3m100-gen4" class="toclink">Who should read this document</a></div>
<div class="head2"><a id="ToC_6" href="e0z3m100.htm#org" class="toclink">How this document is organized</a></div>
<div class="head2"><a id="ToC_7" href="e0z3m100.htm#howtutd" class="toclink">How to use this document</a></div>
<div class="head2"><a id="ToC_8" href="e0z3m100.htm#conterm" class="toclink">Conventions and terminology used in this document</a></div>
<div class="head2"><a id="ToC_9" href="e0z3m100.htm#moreinf" class="toclink">Related information</a></div>
<div class="head1"><a id="ToC_10" href="e0z3m100.htm#mhvrcfs" class="toclink">How to send your comments to IBM</a></div>
<div class="head1"><a id="ToC_11" href="e0z3m100.htm#summaryofchanges" class="toclink">Summary of changes</a></div>
<div class="head1"><a id="ToC_12" href="e0z3m100.htm#migintro" class="toclink">Migration: Introduction</a></div>
<div class="head2"><a id="ToC_13" href="e0z3m100.htm#typmste" class="toclink">Typical migration steps</a></div>
<div class="head2"><a id="ToC_14" href="e0z3m100.htm#eholdda" class="toclink">EPSPT replaced by FIXCAT and REPORT MISSINGFIX</a></div>
<div class="head2"><a id="ToC_15" href="e0z3m100.htm#mighlch" class="toclink">Using IBM Health Checker for z/OS for migration checking</a></div>
<div class="head2"><a id="ToC_16" href="e0z3m100.htm#zosmfloc" class="toclink">z/OS Management Facility</a></div>
<div class="head2"><a id="ToC_17" href="e0z3m100.htm#eafwoma" class="toclink">Elements and features that do not have migration actions</a></div>
<div class="head1"><a id="ToC_18" href="e0z3m100.htm#rel2" class="toclink">General migration actions for everyone migrating to z/OS V2R1</a></div>
<div class="head2"><a id="ToC_19" href="e0z3m100.htm#at1ever2" class="toclink">Migration actions for everyone moving from z/OS V1R13</a></div>
<div class="head3"><a id="ToC_20" href="e0z3m100.htm#e0z3m100-gen6" class="toclink">Migration actions for everyone before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_27" href="e0z3m100.htm#e0z3m100-gen7" class="toclink">Migration actions for everyone before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_43" href="e0z3m100.htm#e0z3m100-gen8" class="toclink">Migration actions for everyone after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_44" href="e0z3m100.htm#au1hard2" class="toclink">Hardware migration actions</a></div>
<div class="head3"><a id="ToC_45" href="e0z3m100.htm#znext21" class="toclink">Migrate to an IBM zEnterprise EC12 server or IBM zEnterprise BC12 server</a></div>
<div class="head3"><a id="ToC_51" href="e0z3m100.htm#mignext" class="toclink">Migrate to an IBM zEnterprise z196 or z114 server</a></div>
<div class="head3"><a id="ToC_60" href="e0z3m100.htm#migrz10" class="toclink">Migrate to a System z10 server</a></div>
<div class="head3"><a id="ToC_67" href="e0z3m100.htm#dt2mg230" class="toclink">Ensure you are running on supported servers and storage controllers</a></div>
<div class="head3"><a id="ToC_68" href="e0z3m100.htm#at3ruio" class="toclink">Replace unsupported devices</a></div>
<div class="head3"><a id="ToC_69" href="e0z3m100.htm#au3ndv" class="toclink">Provide for new device installations</a></div>
<div class="head3"><a id="ToC_70" href="e0z3m100.htm#au3cpfl" class="toclink">Update your CFRM policy with coupling facility structure size changes</a></div>
<div class="head1"><a id="ToC_71" href="e0z3m100.htm#dt2mg235" class="toclink">Migration from z/OS V1R13</a></div>
<div class="head2"><a id="ToC_72" href="e0z3m100.htm#av1pars2" class="toclink">Sysplex migration actions</a></div>
<div class="head3"><a id="ToC_73" href="e0z3m100.htm#e0z3m100-gen19" class="toclink">Sysplex actions related to hardware upgrades</a></div>
<div class="head3"><a id="ToC_74" href="e0z3m100.htm#e0z3m100-gen20" class="toclink">Sysplex actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_75" href="e0z3m100.htm#e0z3m100-gen21" class="toclink">Sysplex actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_76" href="e0z3m100.htm#e0z3m100-gen22" class="toclink">Sysplex actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_77" href="e0z3m100.htm#aa1bcp" class="toclink">BCP migration actions</a></div>
<div class="head3"><a id="ToC_78" href="e0z3m100.htm#e0z3m100-gen98" class="toclink">BCP actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_87" href="e0z3m100.htm#e0z3m100-gen99" class="toclink">BCP actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_100" href="e0z3m100.htm#e0z3m100-gen100" class="toclink">BCP actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_104" href="e0z3m100.htm#bookmanagerbuild" class="toclink">BookManager BUILD migration actions</a></div>
<div class="head3"><a id="ToC_105" href="e0z3m100.htm#bookmanagerbinstall" class="toclink">BookManager BUILD actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_107" href="e0z3m100.htm#bookmbeforeipl" class="toclink">BookManager BUILD actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_108" href="e0z3m100.htm#bookmbafteripl" class="toclink">BookManager BUILD actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head2"><a id="ToC_109" href="e0z3m100.htm#ad1coms" class="toclink">Communications Server migration actions</a></div>
<div class="head3"><a id="ToC_110" href="e0z3m100.htm#e0z3m100-gen101" class="toclink">Communications Server actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_121" href="e0z3m100.htm#e0z3m100-gen27" class="toclink">Communications Server actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_132" href="e0z3m100.htm#e0z3m100-gen28" class="toclink">Communications Server actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_133" href="e0z3m100.htm#ae1cryp" class="toclink">Cryptographic Services migration actions</a></div>
<div class="head3"><a id="ToC_134" href="e0z3m100.htm#e0z3m100-gen29" class="toclink">Cryptographic Services actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_135" href="e0z3m100.htm#e0z3m100-gen106" class="toclink">Cryptographic Services actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_140" href="e0z3m100.htm#e0z3m100-gen31" class="toclink">Cryptographic Services actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_141" href="e0z3m100.htm#af1dfsm" class="toclink">DFSMS migration actions</a></div>
<div class="head3"><a id="ToC_142" href="e0z3m100.htm#e0z3m100-gen32" class="toclink">DFSMS actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_146" href="e0z3m100.htm#e0z3m100-gen33" class="toclink">DFSMS actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_153" href="e0z3m100.htm#e0z3m100-gen34" class="toclink">DFSMS actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_158" href="e0z3m100.htm#dfsomig" class="toclink">DFSORT migration actions</a></div>
<div class="head3"><a id="ToC_159" href="e0z3m100.htm#e0z3m100-gen35" class="toclink">DFSORT actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_160" href="e0z3m100.htm#e0z3m100-gen112" class="toclink">DFSORT actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_164" href="e0z3m100.htm#e0z3m100-gen37" class="toclink">DFSORT actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head2"><a id="ToC_165" href="e0z3m100.htm#dfsmiga" class="toclink">Distributed File Service migration actions</a></div>
<div class="head3"><a id="ToC_166" href="e0z3m100.htm#e0z3m100-gen38" class="toclink">Distributed File Service actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_168" href="e0z3m100.htm#e0z3m100-gen39" class="toclink">Distributed File Service actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_170" href="e0z3m100.htm#e0z3m100-gen40" class="toclink">Distributed File Service actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_171" href="e0z3m100.htm#ibmhttps" class="toclink">IBM HTTP Server migration actions</a></div>
<div class="head3"><a id="ToC_172" href="e0z3m100.htm#ibmhttpsinstall" class="toclink">IBM HTTP Server actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_174" href="e0z3m100.htm#ibmhttpserverbeipl" class="toclink">IBM HTTP Server actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_175" href="e0z3m100.htm#ibmhttpserverafteripl" class="toclink">IBM HTTP Server actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head2"><a id="ToC_176" href="e0z3m100.htm#ai1info1" class="toclink">Infoprint Server migration actions</a></div>
<div class="head3"><a id="ToC_177" href="e0z3m100.htm#e0z3m100-gen117" class="toclink">Infoprint Server actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_179" href="e0z3m100.htm#e0z3m100-gen118" class="toclink">Infoprint Server actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_180" href="e0z3m100.htm#e0z3m100-gen119" class="toclink">Infoprint Server actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_181" href="e0z3m100.htm#ah1jes21" class="toclink">JES2 migration actions</a></div>
<div class="head3"><a id="ToC_182" href="e0z3m100.htm#e0z3m100-gen47" class="toclink">JES2 actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_184" href="e0z3m100.htm#e0z3m100-gen48" class="toclink">JES2 actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_185" href="e0z3m100.htm#e0z3m100-gen49" class="toclink">JES2 actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_188" href="e0z3m100.htm#al1jes31" class="toclink">JES3 migration actions</a></div>
<div class="head3"><a id="ToC_189" href="e0z3m100.htm#e0z3m100-gen123" class="toclink">JES3 actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_190" href="e0z3m100.htm#e0z3m100-gen124" class="toclink">JES3 actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_192" href="e0z3m100.htm#e0z3m100-gen125" class="toclink">JES3 actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_193" href="e0z3m100.htm#ab1bser" class="toclink">Library Server migration actions</a></div>
<div class="head3"><a id="ToC_194" href="e0z3m100.htm#e0z3m100-gen57" class="toclink">Library Server actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_195" href="e0z3m100.htm#libsb1i" class="toclink">Library Server actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_198" href="e0z3m100.htm#e0z3m100-gen58" class="toclink">Library Server actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_200" href="e0z3m100.htm#ao1rmf" class="toclink">RMF migration actions</a></div>
<div class="head3"><a id="ToC_201" href="e0z3m100.htm#e0z3m100-gen59" class="toclink">RMF actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_202" href="e0z3m100.htm#e0z3m100-gen60" class="toclink">RMF actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_209" href="e0z3m100.htm#e0z3m100-gen61" class="toclink">RMF actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_213" href="e0z3m100.htm#ap1sdsf" class="toclink">SDSF migration actions</a></div>
<div class="head3"><a id="ToC_214" href="e0z3m100.htm#e0z3m100-gen62" class="toclink">SDSF actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_215" href="e0z3m100.htm#e0z3m100-gen63" class="toclink">SDSF actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_218" href="e0z3m100.htm#e0z3m100-gen64" class="toclink">SDSF actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_220" href="e0z3m100.htm#aq1secs" class="toclink">Security Server migration actions</a></div>
<div class="head3"><a id="ToC_221" href="e0z3m100.htm#e0z3m100-gen65" class="toclink">Security Server actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_223" href="e0z3m100.htm#e0z3m100-gen66" class="toclink">Security Server actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_227" href="e0z3m100.htm#e0z3m100-gen68" class="toclink">Security Server actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_230" href="e0z3m100.htm#ac1ccpp" class="toclink">XL C/C++ migration actions</a></div>
<div class="head3"><a id="ToC_231" href="e0z3m100.htm#e0z3m100-gen72" class="toclink">XL C/C++ actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_233" href="e0z3m100.htm#e0z3m100-gen73" class="toclink">XL C/C++ actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_234" href="e0z3m100.htm#e0z3m100-gen74" class="toclink">XL C/C++ actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_235" href="e0z3m100.htm#font" class="toclink">z/OS Base Font Collection migration actions</a></div>
<div class="head3"><a id="ToC_236" href="e0z3m100.htm#e0z3m100-gen75" class="toclink">z/OS Base Font Collection actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_237" href="e0z3m100.htm#e0z3m100-gen76" class="toclink">z/OS Base Font Collection actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_239" href="e0z3m100.htm#e0z3m100-gen77" class="toclink">z/OS Base Font Collection actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_240" href="e0z3m100.htm#as1unss" class="toclink">z/OS UNIX migration actions</a></div>
<div class="head3"><a id="ToC_241" href="e0z3m100.htm#e0z3m100-gen151" class="toclink">z/OS UNIX actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_246" href="e0z3m100.htm#e0z3m100-gen79" class="toclink">z/OS UNIX actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_250" href="e0z3m100.htm#e0z3m100-gen80" class="toclink">z/OS UNIX actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head1"><a id="ToC_253" href="e0z3m100.htm#rel1" class="toclink">Migration from z/OS V1R12</a></div>
<div class="head2"><a id="ToC_254" href="e0z3m100.htm#av1pars11" class="toclink">Sysplex migration actions</a></div>
<div class="head3"><a id="ToC_255" href="e0z3m100.htm#dt2mg521" class="toclink">Sysplex actions related to hardware upgrades</a></div>
<div class="head3"><a id="ToC_256" href="e0z3m100.htm#e0z3m100-gen95" class="toclink">Sysplex actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_257" href="e0z3m100.htm#e0z3m100-gen96" class="toclink">Sysplex actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_258" href="e0z3m100.htm#e0z3m100-gen97" class="toclink">Sysplex actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_259" href="e0z3m100.htm#aa1bcp1" class="toclink">BCP migration actions</a></div>
<div class="head3"><a id="ToC_260" href="e0z3m100.htm#dt2mg523" class="toclink">BCP actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_274" href="e0z3m100.htm#dt2mg539" class="toclink">BCP actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_297" href="e0z3m100.htm#dt2mg564" class="toclink">BCP actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_307" href="e0z3m100.htm#dt2mg581" class="toclink">BookManager BUILD migration actions</a></div>
<div class="head3"><a id="ToC_308" href="e0z3m100.htm#dt2mg582" class="toclink">BookManager BUILD actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_310" href="e0z3m100.htm#dt2mg584" class="toclink">BookManager BUILD actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_311" href="e0z3m100.htm#dt2mg585" class="toclink">BookManager BUILD actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head2"><a id="ToC_312" href="e0z3m100.htm#cim" class="toclink">CIM migration actions</a></div>
<div class="head3"><a id="ToC_313" href="e0z3m100.htm#bookciminstall" class="toclink">CIM actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_314" href="e0z3m100.htm#cimbeforeipl" class="toclink">CIM actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_315" href="e0z3m100.htm#cimbafteripl" class="toclink">CIM actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head2"><a id="ToC_317" href="e0z3m100.htm#ad1coms1" class="toclink">Communications Server migration actions</a></div>
<div class="head3"><a id="ToC_318" href="e0z3m100.htm#dt2mg591" class="toclink">Communications Server actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_341" href="e0z3m100.htm#e0z3m100-gen103" class="toclink">Communications Server actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_355" href="e0z3m100.htm#e0z3m100-gen104" class="toclink">Communications Server actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_356" href="e0z3m100.htm#ae1cryp1" class="toclink">Cryptographic Services migration actions</a></div>
<div class="head3"><a id="ToC_357" href="e0z3m100.htm#e0z3m100-gen105" class="toclink">Cryptographic Services actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_358" href="e0z3m100.htm#dt2mg648" class="toclink">Cryptographic Services actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_365" href="e0z3m100.htm#e0z3m100-gen107" class="toclink">Cryptographic Services actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_367" href="e0z3m100.htm#af1dfsm1" class="toclink">DFSMS migration actions</a></div>
<div class="head3"><a id="ToC_368" href="e0z3m100.htm#e0z3m100-gen108" class="toclink">DFSMS actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_374" href="e0z3m100.htm#e0z3m100-gen109" class="toclink">DFSMS actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_391" href="e0z3m100.htm#e0z3m100-gen110" class="toclink">DFSMS actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_399" href="e0z3m100.htm#dfsomig1" class="toclink">DFSORT migration actions</a></div>
<div class="head3"><a id="ToC_400" href="e0z3m100.htm#e0z3m100-gen111" class="toclink">DFSORT actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_401" href="e0z3m100.htm#dt2mg686" class="toclink">DFSORT actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_405" href="e0z3m100.htm#e0z3m100-gen113" class="toclink">DFSORT actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_406" href="e0z3m100.htm#dfsmiga1" class="toclink">Distributed File Service migration actions</a></div>
<div class="head3"><a id="ToC_407" href="e0z3m100.htm#e0z3m100-gen114" class="toclink">Distributed File Service actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_417" href="e0z3m100.htm#e0z3m100-gen115" class="toclink">Distributed File Service actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_419" href="e0z3m100.htm#e0z3m100-gen116" class="toclink">Distributed File Service actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_420" href="e0z3m100.htm#dt2mg699" class="toclink">IBM HTTP Server migration actions</a></div>
<div class="head3"><a id="ToC_421" href="e0z3m100.htm#dt2mg700" class="toclink">IBM HTTP Server actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_423" href="e0z3m100.htm#dt2mg702" class="toclink">IBM HTTP Server actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_424" href="e0z3m100.htm#dt2mg703" class="toclink">IBM HTTP Server actions to perform after the first IPL of z/OS V1R13</a></div>
<div class="head2"><a id="ToC_425" href="e0z3m100.htm#dt2mg704" class="toclink">Infoprint Server migration actions</a></div>
<div class="head3"><a id="ToC_426" href="e0z3m100.htm#dt2mg705" class="toclink">Infoprint Server actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_429" href="e0z3m100.htm#dt2mg709" class="toclink">Infoprint Server actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_432" href="e0z3m100.htm#dt2mg712" class="toclink">Infoprint Server actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_434" href="e0z3m100.htm#dt2mg716" class="toclink">JES2 migration actions</a></div>
<div class="head3"><a id="ToC_435" href="e0z3m100.htm#e0z3m100-gen120" class="toclink">JES2 actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_437" href="e0z3m100.htm#dt2mg718" class="toclink">JES2 actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_438" href="e0z3m100.htm#e0z3m100-gen122" class="toclink">JES2 actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_443" href="e0z3m100.htm#dt2mg724" class="toclink">JES3 migration actions</a></div>
<div class="head3"><a id="ToC_444" href="e0z3m100.htm#dt2mg725" class="toclink">JES3 actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_445" href="e0z3m100.htm#dt2mg726" class="toclink">JES3 actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_451" href="e0z3m100.htm#dt2mg731" class="toclink">JES3 actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_452" href="e0z3m100.htm#am1lenv1" class="toclink">Language Environment migration actions</a></div>
<div class="head3"><a id="ToC_453" href="e0z3m100.htm#e0z3m100-gen126" class="toclink">Language Environment actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_454" href="e0z3m100.htm#e0z3m100-gen127" class="toclink">Language Environment actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_461" href="e0z3m100.htm#e0z3m100-gen128" class="toclink">Language Environment actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_462" href="e0z3m100.htm#ab1bser1" class="toclink">Library Server migration actions</a></div>
<div class="head3"><a id="ToC_463" href="e0z3m100.htm#e0z3m100-gen129" class="toclink">Library Server actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_464" href="e0z3m100.htm#libsb1i1" class="toclink">Library Server actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_467" href="e0z3m100.htm#e0z3m100-gen130" class="toclink">Library Server actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_469" href="e0z3m100.htm#ao1rmf1" class="toclink">RMF migration actions</a></div>
<div class="head3"><a id="ToC_470" href="e0z3m100.htm#e0z3m100-gen131" class="toclink">RMF actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_471" href="e0z3m100.htm#e0z3m100-gen132" class="toclink">RMF actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_479" href="e0z3m100.htm#e0z3m100-gen133" class="toclink">RMF actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_484" href="e0z3m100.htm#ap1sdsf1" class="toclink">SDSF migration actions</a></div>
<div class="head3"><a id="ToC_485" href="e0z3m100.htm#e0z3m100-gen134" class="toclink">SDSF actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_486" href="e0z3m100.htm#e0z3m100-gen135" class="toclink">SDSF actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_489" href="e0z3m100.htm#e0z3m100-gen136" class="toclink">SDSF actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_494" href="e0z3m100.htm#aq1secs1" class="toclink">Security Server migration actions</a></div>
<div class="head3"><a id="ToC_495" href="e0z3m100.htm#e0z3m100-gen137" class="toclink">Security Server actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_498" href="e0z3m100.htm#e0z3m100-gen139" class="toclink">Security Server actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_502" href="e0z3m100.htm#e0z3m100-gen141" class="toclink">Security Server actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_505" href="e0z3m100.htm#ac1ccpp1" class="toclink">XL C/C++ migration actions</a></div>
<div class="head3"><a id="ToC_506" href="e0z3m100.htm#e0z3m100-gen145" class="toclink">XL C/C++ actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_508" href="e0z3m100.htm#e0z3m100-gen146" class="toclink">XL C/C++ actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_509" href="e0z3m100.htm#e0z3m100-gen147" class="toclink">XL C/C++ actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_510" href="e0z3m100.htm#font1" class="toclink">z/OS Base Font Collection migration actions</a></div>
<div class="head3"><a id="ToC_511" href="e0z3m100.htm#e0z3m100-gen148" class="toclink">z/OS Base Font Collection actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_512" href="e0z3m100.htm#e0z3m100-gen149" class="toclink">z/OS Base Font Collection actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_514" href="e0z3m100.htm#e0z3m100-gen150" class="toclink">z/OS Base Font Collection actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head2"><a id="ToC_515" href="e0z3m100.htm#as1unss1" class="toclink">z/OS UNIX migration actions</a></div>
<div class="head3"><a id="ToC_516" href="e0z3m100.htm#dt2mg777" class="toclink">z/OS UNIX actions to perform before installing z/OS V2R1</a></div>
<div class="head3"><a id="ToC_524" href="e0z3m100.htm#e0z3m100-gen152" class="toclink">z/OS UNIX actions to perform before the first IPL of z/OS V2R1</a></div>
<div class="head3"><a id="ToC_530" href="e0z3m100.htm#e0z3m100-gen153" class="toclink">z/OS UNIX actions to perform after the first IPL of z/OS V2R1</a></div>
<div class="head1"><a id="ToC_534" href="e0z3m100.htm#access" class="toclink">Appendix. Accessibility features for CSM</a></div>
<div class="head2"><a id="ToC_535" href="e0z3m100.htm#e0z3m100-gen154" class="toclink">Using assistive technologies</a></div>
<div class="head2"><a id="ToC_536" href="e0z3m100.htm#e0z3m100-gen155" class="toclink">Keyboard navigation of the user interface</a></div>
<div class="head2"><a id="ToC_537" href="e0z3m100.htm#e0z3m100-gen156" class="toclink">z/OS information</a></div>
<div class="head1"><a id="ToC_538" href="e0z3m100.htm#notice" class="toclink">Notices</a></div>
<div class="head2"><a id="ToC_539" href="e0z3m100.htm#unsupphw" class="toclink">Policy for unsupported hardware</a></div>
<div class="head2"><a id="ToC_540" href="e0z3m100.htm#minimumsupportedhardware" class="toclink">Minimum supported hardware</a></div>
<div class="head1"><a id="ToC_541" href="e0z3m100.htm#idg15543" class="toclink">Trademarks</a></div>
<div class="head1"><a id="ToC_542" href="e0z3m100.htm#wq678" class="toclink">Index</a></div>
</div>
<h1 id="wq4">Figures</h1>
<ol class="figlist">
<li><a id="FT_Figure_1" href="e0z3m100.htm#grsficon1__rollipl1" class="figurelist">Example of a rolling IPL on a three-system GRS ring</a></li>
</ol>
<h1 id="wq5">Tables</h1>
<ol class="tablelist">
<li><a id="FT_Table_1" href="e0z3m100.htm#pspbuck__psptable" class="tablelist">Servers, upgrades, and FIXCAT values</a></li>
<li><a id="FT_Table_2" href="e0z3m100.htm#at3gena__ipcsdsc" class="tablelist">IPCS data set requirements for a logon procedure or DD name allocation</a></li>
<li><a id="FT_Table_3" href="e0z3m100.htm#at3gene__ldtab1" class="tablelist">Data sets and paths <strong>deleted</strong> from z/OS V2R1 (in alphabetic order by DDDEF name)</a></li>
<li><a id="FT_Table_4" href="e0z3m100.htm#at3gene__ldtab2" class="tablelist">Data sets and paths <strong>deleted</strong> from z/OS V1R13 (in alphabetic order by DDDEF name)Data sets and paths <strong>deleted</strong> from z/OS V1R13 (in alphabetic order by DDDEF name)</a></li>
<li><a id="FT_Table_5" href="e0z3m100.htm#at3genf__dsadded" class="tablelist">Data sets <strong>added</strong> to z/OS V2R1 and z/OS V1R13 (in alphabetic order by DDDEF name)</a></li>
<li><a id="FT_Table_6" href="e0z3m100.htm#znext21__znextfuncbc" class="tablelist">zEC12 and zBC12 server functions included in the base support for z/OS V1R12, z/OS V1R13, and z/OS V2R1</a></li>
<li><a id="FT_Table_7" href="e0z3m100.htm#znext21__znextbcexp1" class="tablelist">Exploitation of zEC12 and zBC12 server functions supported by z/OS V1R12, z/OS V1R13, and z/OS V2R1</a></li>
<li><a id="FT_Table_8" href="e0z3m100.htm#mignext__zentfunc2" class="tablelist">zEnterprise functions included in base z/OS supported for z/OS V1R12, z/OS V1R13, and z/OS V2R1</a></li>
<li><a id="FT_Table_9" href="e0z3m100.htm#mignext__zentfexp1" class="tablelist">zEnterprise functions exploited by z/OS V1R12, z/OS V1R13, and z/OS V2R1</a></li>
<li><a id="FT_Table_10" href="e0z3m100.htm#upcsetc__csetctb" class="tablelist">Changed Communications Server configuration files</a></li>
<li><a id="FT_Table_11" href="e0z3m100.htm#wq283" class="tablelist">Examples of IP matches</a></li>
<li><a id="FT_Table_12" href="e0z3m100.htm#fontcol1__fontsincludedinthezosfontcollection" class="tablelist">Existing font products and replacements in the z/OS Font Collection base element</a></li>
<li><a id="FT_Table_13" href="e0z3m100.htm#dt2mg642" class="tablelist">Changed Communications Server configuration files</a></li>
<li><a id="FT_Table_14" href="e0z3m100.htm#filesyszfs__zfsemsg" class="tablelist">Examples of zFS error messages</a></li>
<li><a id="FT_Table_15" href="e0z3m100.htm#wq609" class="tablelist">Examples of IP matches</a></li>
<li><a id="FT_Table_16" href="e0z3m100.htm#dt2mg776" class="tablelist">Existing font products and replacements in the z/OS Font Collection base element</a></li>
</ol>
<h1 id="about">About this document</h1>
<p>This document describes how to migrate <strong>to</strong> z/OS&reg; Version 2 Release 1 (V2R1) <strong>from</strong> the
following releases:  
</p>
<ul>
<li>z/OS V1R13</li>
<li>z/OS V1R12</li></ul>
<p>The document is arranged in parts with chapters 1 and
2 as an introduction for everyone who performs z/OS migration actions
regardless of the migration path and migration paths for hardware,
chapter 3 for those customers migrating from z/OS V1R13, and chapter
4 for those customers migrating from z/OS V1R12. For chapters 3 and
4 only those actions for the specific migration path are documented.
See <a href="e0z3m100.htm#org">How this document is organized</a>.</p>
<p>This document does not explain how to exploit new functions in z/OS. For that information, see
the many publications that pertain to the z/OS base elements and optional features.</p>
<h2 id="e0z3m100-gen4">Who should read this document</h2><a id="idx1"></a><a id="idx2"></a><a id="idx3"></a>
<p>This document is intended for system analysts, system programmers,
system administrators, security administrators, network administrators,
database administrators, and other members of an information technology
team who have experience installing and managing z/OS, and want to plan for and implement the installation
of z/OS V2R1.</p>
<h2 id="org">How this document is organized</h2><a id="idx4"></a><a id="idx5"></a>
<p>This document is organized into the following parts: 
</p>
<ul>
<li><a href="e0z3m100.htm#migintro">Migration: Introduction</a> is general in scope
and for all users, that is, not devoted to a specific z/OS base element
or optional feature, or specific migration path. It includes the following
topics: 

<ul>
<li><a href="e0z3m100.htm#typmste">Typical migration steps</a></li>
<li><a href="e0z3m100.htm#eholdda">EPSPT replaced by FIXCAT and REPORT MISSINGFIX</a>.</li>
<li><a href="e0z3m100.htm#mighlch">Using IBM Health Checker
for z/OS for migration checking</a>.</li>
<li><a href="e0z3m100.htm#zosmfloc">z/OS Management Facility</a>.</li>
<li><a href="e0z3m100.htm#eafwoma">Elements and features that do not have migration actions</a></li></ul></li>
<li><a href="e0z3m100.htm#rel2">General migration actions for everyone migrating to z/OS V2R1</a> is
general in scope and for all users, that is, not devoted to a specific
z/OS base element or optional feature. It includes the following topics: 

<ul>
<li><a href="e0z3m100.htm#at1ever2">Migration actions for everyone moving from z/OS V1R13</a></li>
<li><a href="e0z3m100.htm#e0z3m100-gen6">Migration actions for everyone before installing z/OS V2R1</a>.</li>
<li><a href="e0z3m100.htm#e0z3m100-gen8">Migration actions for everyone after the first IPL of z/OS V2R1</a>.</li>
<li><a href="e0z3m100.htm#au1hard2">Hardware migration actions</a>.</li></ul></li>
<li><a href="e0z3m100.htm#dt2mg235">Migration from z/OS V1R13</a> is
a customized path for migration from z/OS V1R13 to z/OS V2R1. It includes
topics devoted to the specific elements and features that have migration
actions, with one element or feature per chapter. These topics are
in alphabetic order -- from BCP (<a href="e0z3m100.htm#aa1bcp">BCP migration actions</a>)
to z/OS UNIX (<a href="e0z3m100.htm#as1unss">z/OS UNIX migration
actions</a>).
Within each topic, the following standard organization is used: 

<ul class="simple">
<li>Migration actions to perform <em>before installing</em> z/OS V2R1</li>
<li>Migration actions to perform <em>before the first IPL</em> of z/OS V2R1</li>
<li>Migration actions to perform <em>after the first IPL</em> of z/OS V2R1</li></ul></li>
<li><a href="e0z3m100.htm#rel1">Migration from z/OS V1R12</a> is
a customized path for migration from z/OS V1R12 to z/OS V2R1. It includes
topics devoted to the specific elements and features that have migration
actions, with one element or feature per chapter. These topics are
in alphabetic order -- from BCP (<a href="e0z3m100.htm#aa1bcp1">BCP migration actions</a>)
to z/OS UNIX (<a href="e0z3m100.htm#as1unss1">z/OS UNIX migration actions</a>).
Within each topic, the following standard organization is used: 

<ul class="simple">
<li>Migration actions to perform <em>before installing</em> z/OS V2R1</li>
<li>Migration actions to perform <em>before the first IPL</em> of z/OS V2R1</li>
<li>Migration actions to perform <em>after the first IPL</em> of z/OS V2R1</li></ul></li></ul>
<h2 id="howtutd">How to use this document</h2><a id="idx6"></a><a id="idx7"></a><a id="idx8"></a>
<p>Use this document as your initial source for z/OS migration information. Where appropriate,
this document refers you to other documents for additional information.</p>
<p>Within this document, read <a href="e0z3m100.htm#migintro">Migration: Introduction</a> and <a href="e0z3m100.htm#rel2">General migration actions for everyone migrating to z/OS V2R1</a> regardless
of your particular migration path from an earlier release.</p>
<p>If you are migrating from z/OS V1R13, go to <a href="e0z3m100.htm#dt2mg235">Migration from z/OS V1R13</a> and proceed sequentially
through the subsequent topics or in whatever order you prefer based
on element or feature interest. The topics are in alphabetic order
by name of element or feature, once you pass the topic on migration
actions for everyone, the topic on hardware migration actions, and
the topic on sysplex migration actions</p>
<p>If you are migrating from z/OS V1R12, go to <a href="e0z3m100.htm#rel1">Migration from z/OS V1R12</a> and proceed sequentially
through the subsequent topics or in whatever order you prefer based
on element or feature interest.</p>
<p>The topics in are in alphabetic order by name of element or feature,
once you pass the topic on migration actions for everyone, the topic
on hardware migration actions, and the topic on sysplex migration
actions.</p>
<p>Another way to proceed is to concentrate first on preinstall migration
actions within each topic for the appropriate migration path, then
pre-IPL migration actions, and then post-IPL migration actions. These
actions are clearly identified by major headings within each topic
in the appropriate chapter.</p>
<h2 id="conterm">Conventions and terminology used in this document</h2><a id="idx9"></a><a id="idx10"></a><a id="idx11"></a>
<p>When this document refers to <strong><span class="bold-italic">IBM&reg; System z&reg;</span></strong> servers without
stating a specific server, it refers to all of the following servers: 
</p>
<ul>
<li>IBM zEnterprise BC12 (zBC12)</li>
<li>IBM zEnterprise EC12 (zEC12)</li>
<li>IBM zEnterprise<sup>TM</sup> 114
(z114)</li>
<li>IBM zEnterprise<sup>TM</sup> 196
(z196)</li>
<li>IBM System z10&trade; Enterprise Class (z10 EC)</li>
<li>IBM System z10 Business Class (z10 BC)</li>
<li>IBM System z9&reg; Enterprise Class (z9 EC),
formerly the IBM System z9 109 (z9-109)</li>
<li>IBM System z9 Business Class (z9 BC)</li>
<li>IBM eServer&trade; zSeries&reg; 990
(z990)</li>
<li>IBM eServer zSeries 890
(z890)</li>
<li>IBM eServer zSeries 900
(z900)</li>
<li>IBM eServer zSeries 800
(z800)</li></ul>
<p>Important terms you should understand are: 
</p>
<ul>
<li><strong><span class="bold-italic">Migration.</span></strong> <a id="idx12"></a>Migration
is the first of two stages in an upgrade to a new release of z/OS. (The second stage is exploitation.)
During this stage you install your new system with the objective of
making it functionally compatible with the previous system. After
a successful migration, the applications and resources on the new
system function the same way (or similar to the way) they did on the
old system or, if that is not possible, in a way that accommodates
the new system differences so that existing workloads can continue
to run. Migration does not include exploitation of new functions except
for new functions that are now required.</li>
<li><strong><span class="bold-italic">Exploitation.</span></strong> <a id="idx13"></a>Exploitation is the second of two stages in an upgrade
to a new release of z/OS. (The
first stage is migration.) During this stage you do whatever customizing
and programming are necessary to take advantage of (exploit) the enhancements
available in the new release.</li>
<li><strong><span class="bold-italic">Coexistence.</span></strong> <a id="idx14"></a>Coexistence is the situation in which two
or more systems at different software levels share resources. The
resources could be shared at the same time by different systems in
a multisystem configuration, or they could be shared over a period
of time by the same system in a single-system configuration. 

<p>Examples
of coexistence are two different JES releases sharing a spool, two
different service levels of DFSMSdfp sharing catalogs, multiple levels
of SMP/E processing SYSMODS packaged to exploit the latest enhancements,
or an older level of the system using the updated system control files
of a newer level (even if new function has been exploited in the newer
level).</p> 

<p>The sharing of resources is inherent in multisystem
configurations that involve Parallel Sysplex&reg; implementations. But other types of configurations can
have resource sharing too. Examples of configurations where resource
sharing can occur are: 
</p>
<ul>
<li>A single processor that is time-sliced to run different levels
of the system, such as during different times of the day</li>
<li>A single processor running multiple images by means of logical
partitions (LPARs)</li>
<li>Multiple images running on several different processors in either Parallel Sysplex or
non-Parallel Sysplex configurations</li></ul> 

<p>The way in which you make it possible for earlier-level
systems to coexist with the most current level is to install coexistence
and fallback PTFs on the earlier-level systems.</p></li>
<li><strong><span class="bold-italic">Fallback.</span></strong> <a id="idx15"></a>Fallback is a return to the prior level
of a system. Fallback can be appropriate if you migrate to a new release
and, during testing, encounter severe problems that can be resolved
by backing out the new release. By installing coexistence and fallback
PTFs on the &quot;old&quot; system before you migrate, the old system can
tolerate changes that were made by the new system during testing.</li></ul>
<p>To identify the timing of migration actions, this document uses
three types of headings: 
</p>
<ul>
<li><strong><span class="bold-italic">Actions to perform Before installing z/OS V2R1.</span></strong> <a id="idx16"></a><a id="idx17"></a>These
are migration actions that you perform on your current system, either
because they require the current system or because they are possible
on the current system. You do not need the z/OS V2R1 level of code to make these changes,
and the changes do not require the z/OS V2R1
level of code to run once they are made. Examples are installing coexistence
and fallback PTFs on your current system, discontinuing use of hardware
or software that will no longer be supported, and starting to use
existing functions that were optional on prior releases but required
in z/OS V2R1.</li>
<li><strong><span class="bold-italic">Actions to perform before the first IPL of z/OS V2R1.</span></strong><a id="idx18"></a><a id="idx19"></a> These
are migration actions that you perform after you have installed z/OS V2R1 but before the first
time you IPL. These actions require the z/OS V2R1
level of code to be installed but do not require it to be active.
That is, you need the z/OS V2R1
programs, utilities, and samples in order to perform the migration
actions, but the z/OS V2R1
system does not have to be IPLed in order for the programs to run.
Examples are running sysplex utilities and updating the RACF&reg; database template. 

<p>It is possible to
perform some of the migration actions in this category even earlier.
If you prepare a system on which you will install z/OS V2R1 by making a clone of your old system,
you can perform migration actions that involve customization data
on this newly prepared system before installing z/OS V2R1 on it. Examples of such migration
actions are updating configuration files and updating automation scripts.</p></li>
<li><strong><span class="bold-italic">Actions to perform after the first IPL of z/OS V2R1.</span></strong> <a id="idx20"></a><a id="idx21"></a>These
are migration actions that you can perform only after you have IPLed z/OS V2R1. You need a running z/OS V2R1 system to perform these
actions. An example is issuing RACF commands
related to new functions. Note that the term &quot;first IPL&quot; does
not mean that you have to perform these actions after the very first
IPL, but rather that you need z/OS V2R1
to be active to perform the task. You might perform the task quite
a while after the first IPL.</li></ul>
<p>Each migration action within the headings described is presented
using the following standard format: 
</p>
<ul>
<li>A title that identifies the migration action.</li>
<li><strong><span class="bold-italic">Description.</span></strong> <a id="idx22"></a>This
is a brief description of the functional change that caused the migration
action.</li>
<li><strong><span class="bold-italic">Element or feature.</span></strong> This is the name of the base
element or optional feature that changed.</li>
<li><strong><span class="bold-italic">When change was introduced.</span></strong> <a id="idx23"></a>This is the z/OS release in which the change was introduced.</li>
<li><strong><span class="bold-italic">Applies to migration from.</span></strong> The migration action
is relevant if you are migrating from this release.</li>
<li><strong><span class="bold-italic">Timing.</span></strong> This is when you should perform the migration
action. There are three categories: before installing z/OS, before first IPL, or after first IPL.
(For SMP/E there are two categories: after installing SMP/E but before
starting to use it, and after starting to use SMP/E.)</li>
<li><strong><span class="bold-italic">Is the migration action required?</span></strong> <a id="idx24"></a>This question refers to the migration
action identified by the title. The answer can be one of the following: 

<ul>
<li><em>Yes.</em> The migration action is required in all cases.</li>
<li><em>Yes, if...</em> The migration action is required only in a certain
case. Most of the migration actions in this document are in this category.</li>
<li><em>No, but recommended...</em> The migration action is not required
but is recommended because it is a good programming practice, because
it will be required in the future, or because it resolves unacceptable
system behavior (such as poor usability or poor performance) even
though resolution might require a change in behavior.</li></ul></li>
<li><strong><span class="bold-italic">Target system hardware requirements.</span></strong> <a id="idx25"></a>This is hardware
required by the functional change. It could be processor and peripheral
devices; drivers, engineering changes, or patches needed; or specific
hardware functions that must be active.</li>
<li><strong><span class="bold-italic">Target system software requirements.</span></strong> <a id="idx26"></a>This is software
required by the functional change. It could be z/OS optional features, software products, and
PTFs that are needed on the target system, as well as specific software
functions that must be active.</li>
<li><strong><span class="bold-italic">Other system (coexistence or fallback) requirements.</span></strong> <a id="idx27"></a>These
are requirements placed on an earlier release by the functional change
in the new release. The earlier release could be running on a system
that shares resources (coexists) with the new system or it could be
the release from which you are migrating (and to which you might want
to fall back).</li>
<li><strong><span class="bold-italic">Restrictions.</span></strong> <a id="idx28"></a>These
are any known limits on how the function can be used.</li>
<li><strong><span class="bold-italic">System impacts.</span></strong> <a id="idx29"></a>These are any known impacts of using the function, such
as increased storage or more time required to run.</li>
<li><strong><span class="bold-italic">Related IBM Health
Checker for z/OS check.</span></strong> <a id="idx30"></a>These are IBM Health Checker for z/OS checks available for the migration action.</li>
<li><strong><span class="bold-italic">Steps to take.</span></strong> <a id="idx31"></a>This is what you have to do to perform the migration
action.</li>
<li><strong><span class="bold-italic">Reference information.</span></strong> <a id="idx32"></a>This is a pointer to additional information
that helps you perform the migration action.</li></ul>
<p>The order in which the migration actions are presented does not
imply importance or chronology.</p>
<h2 id="moreinf">Related information</h2><a id="idx33"></a><a id="idx34"></a><a id="idx35"></a><a id="idx36"></a>
<p>See <cite>z/OS Introduction and Release Guide</cite> for
an introduction to z/OS and
an overview of the new functions in each release of z/OS.</p>
<p>See <cite>z/OS Planning
for Installation</cite> for a summary of installation changes
in each release of z/OS, driving
system hardware and software requirements, target system hardware
and software requirements, the coexistence-migration-fallback policy,
required releases of IBM middleware
products, and considerations for planning future installations.</p>
<p>To view, search, and print z/OS publications,
go to the z/OS Internet Library
at <a href=" http://www.ibm.com/systems/z/os/zos/bkserv/">http://www.ibm.com/eserver/zseries/zos/bkserv/</a>.<a id="idx37"></a><a id="idx38"></a><a id="idx39"></a></p>
<h1 id="mhvrcfs">How to send your comments to IBM</h1>
<p>We appreciate your input on this publication. Feel free to comment
on the clarity, accuracy, and completeness of the information or give
us any other feedback that you might have.</p>
<p>Use one of the following methods to send us your comments:
</p>
<ol type="1">
<li>Send an email to mhvrcfs@us.ibm.com</li>
<li>Visit the <a href="http://www.ibm.com/systems/z/os/zos/webqs.html" target="_blank">Contact z/OS</a> web
page at <a href="http://www.ibm.com/systems/z/os/zos/webqs.html" target="_blank">http://www.ibm.com/systems/z/os/zos/webqs.html</a></li>
<li>Mail the comments to the following address: 

<ul>
<li>IBM Corporation</li>
<li>Attention: MHVRCFS Reader Comments</li>
<li>Department H6MA, Building 707</li>
<li>2455 South Road</li>
<li>Poughkeepsie, NY  12601-5400</li>
<li>U.S.A.</li></ul></li>
<li>Fax the comments to us as follows:

<ul>
<li>From the United States and Canada:  1+845+432-9405</li>
<li>From all other countries: Your international access code +1+845+432-9405</li></ul></li></ol>
<p>Include the following information:
</p>
<ul>
<li>Your name and address</li>
<li>Your email address</li>
<li>Your telephone or fax number</li>
<li>The publication title and order number: 

<ul>
<li>z/OS V2R1 Migration</li>
<li>GA32-0889</li></ul></li>
<li>The topic and page number related to your comment</li>
<li>The text of your comment.</li></ul><p class="indatacontent">When you send comments to IBM, you grant IBM a nonexclusive right
to use or distribute your comments in any way it believes appropriate
without incurring any obligation to you.</p>
<p>IBM or any other organizations will only use the personal information
that you supply to contact you about the issues that you submit.</p>
<h1 id="summaryofchanges">Summary of changes</h1>
<div>
<p></p></div>
<p><strong>Changes made in z/OS Version 2 Release 1</strong>:</p>
<p>This document contains information previously presented in GA22-7499-21,
which supports z/OS Version 1 Release 13.</p>
<p><strong>New information</strong>:
</p>
<ul>
<li>TBD next draft</li></ul>
<p><strong>Changed information</strong>:
</p>
<ul>
<li>TBD next draft</li></ul>
<p><strong>Deleted information</strong>:
</p>
<ul>
<li>TBD next draft</li></ul>
<h1 id="migintro">Migration: Introduction</h1>
<div>
<p>Part 1 is an introduction to z/OS Migration for both z/OS V1R12 and z/OS V1R13 users
who are migrating to z/OS V2R1.</p></div>
<h2 id="typmste">Typical migration steps</h2>
<p>It is possible to make migration changes at the same time you make
the changes necessary to exploit new functions in the new release.
However, the more prudent approach is to do your migration first and
then exploit new functions. The typical steps to accomplish this are:<a id="idx40"></a><a id="idx41"></a><a id="idx42"></a></p>
<ol type="1">
<li>Learn about z/OS V2R1. Good
sources of information are <cite>z/OS Introduction and Release Guide</cite>, <cite>z/OS Planning
for Installation</cite>,
and <a href=" http://www.ibm.com/systems/z/os/zos/">http://www.ibm.com/eserver/zseries/zos/</a>.</li>
<li>Perform as many of the migration actions as you can on your existing
(&quot;old&quot;) system so that you have fewer actions to perform after
you install z/OS V2R1.
In this information, the actions you can perform on your existing
system are identified by headings that say <strong>Actions to perform before
installing z/OS V2R1</strong>.
(Note that not all of the actions are required. Some depend on your
environment, configuration, and workload, and are identified accordingly.)
These actions should be made to, or copied (cloned) to, all existing
systems that will be migrated to z/OS V2R1. 

<p>Use IBM Health Checker for z/OS to assist with some migration actions.
See <a href="e0z3m100.htm#mighlch">Using IBM Health Checker
for z/OS for migration checking</a>.</p></li>
<li>Order and install coexistence and fallback service for any system
that will share resources with a z/OS V2R1 system.
 (See <a href="e0z3m100.htm#coxptfs">Install coexistence and fallback PTFs</a>.) This service needs
to be installed on all systems that will coexist with z/OS V2R1 and
all systems that will be migrated to z/OS V2R1 (and
which you might fall back to).</li>
<li>Prepare the driving system. For driving system requirements, see
the topic about  in <cite>z/OS Planning
for Installation</cite>.</li>
<li>Order and install z/OS V2R1. If
you use a ServerPac, refer to <cite>ServerPac: Installing Your Order</cite>.
If you use a CBPDO, refer to <cite>z/OS Program Directory</cite>.</li>
<li>Prepare target system hardware and software. During this step,
perform the migration actions identified by headings that say <strong>actions
to perform before the first IPL of z/OS V2R1</strong>.
(Again, not all of the actions are required. Some depend on your environment,
configuration, and workload, and are identified accordingly.)</li>
<li>IPL the new z/OS V2R1 system
with your updated customization and configuration files.</li>
<li>Perform any migration actions identified by headings that say <strong>actions
to perform after the first IPL of z/OS V2R1</strong>.
(Again, not all of the actions are required. Some depend on your environment,
configuration, and workload, and are identified accordingly.) 

<p>Use IBM Health Checker for z/OS to assist with some migration actions.
See <a href="e0z3m100.htm#mighlch">Using IBM Health Checker
for z/OS for migration checking</a>.</p></li>
<li>Deploy z/OS V2R1 to
other systems within a sysplex, data center, and enterprise. 

<p><strong><span class="bold-italic">The
migration is now complete.</span></strong></p></li>
<li>When you are confident that a system, or in some cases
all systems in a sysplex, are not going to fall back to z/OS V1R13 or
z/OS z/OS V1R12 exploit
the functions introduced in z/OS V2R1.</li>
<li>Deploy this exploitation on other systems (again within a sysplex,
data center, and eventually enterprise).</li></ol>
<h2 id="eholdda">EPSPT replaced by FIXCAT and REPORT MISSINGFIX</h2><a id="idx43"></a><a id="idx44"></a><a id="idx45"></a><a id="idx46"></a>
<p>IBM removed the Enhanced
PSP Tool (EPSPT), host compare program, and the associated extract
files from the IBM Technical
Support web site (<a href="http://www14.software.ibm.com/webapp/set2/psp/srchBroker">http://www14.software.ibm.com/webapp/set2/psp/srchBroker</a>),
effective 31 December 2010. The Enhanced PSP Tool's function has been
replaced by the addition of FIXCAT (fix category) information to Enhanced
HOLDDATA and the REPORT MISSINGFIX function introduced in z/OS V1R10 SMP/E, which offers
distinct advantages over the Enhanced PSP Tool. This SMP/E function
is also available for all supported releases of z/OS in SMP/E for z/OS V3R6 (5655-G44), which you
can order separately.</p>
<h2 id="mighlch">Using IBM Health Checker
for z/OS for migration checking</h2><a id="idx47"></a><a id="idx48"></a><a id="idx49"></a>
<p>Beginning with z/OS V1R10, the IBM Health
Checker for z/OS infrastructure
is being exploited for migration purposes. Checks are being added
to help you determine the applicability of various migration actions.
Before you migrate to your new z/OS release, you should use these
new checks to assist with migration planning. After you migrate, you
should rerun them to verify that the migration actions were successfully
performed. As with any IBM Health
Checker for z/OS check, no updates are made to the system. These new
migration checks only report on the applicability of specific migration
actions on a system, and only on the currently active system.</p>
<p>The migration checks are very similar to the other checks provided
by IBM Health Checker for z/OS. The only differences are: 
</p>
<ul>
<li>The names of migration checks follow the convention <strong>ZOSMIGV<span class="synph"><span class="var">vv</span></span>R<span class="synph"><span class="var">rr_component_program_name</span></span></strong> (or,
for ICSF, <strong>ICSFMIG<span class="synph"><span class="var">nnnn_component_program_name</span></span></strong>).
Notice the &quot;MIG&quot; characters followed immediately by the release
identifier. This convention tells you that the check helps with migration
and it tells you the release in which the migration action was introduced. If
the release in which the migration action was introduced is not known,
the name will be ZOSMIGREC.</li>
<li>By default, migration checks are inactive. This is because you
might not want to know about migration actions during nonmigration
periods.</li></ul>
<p id="mighlch__rexhlth"><strong>System REXX health check considerations</strong>:</p>
<p>All exploiters of the System REXX support in z/OS require that the System REXX customization
be performed. Using the IBM Health
Checker for z/OS health checks is one example of possible System REXX
exploitation. In particular, any compiled REXX execs must have the
proper runtime support available from the Alternate Library for REXX
(available in z/OS since V1R9)
or from the IBM Library for
REXX on zSeries (5695-014).
  Several IBM Health Checker
for z/OS migration health checks
have been written in compiled System REXX.  These health checks rely
upon the System REXX customization and runtime activities being completed.
 If System REXX (and the security environment that System REXX requires)
have not been properly customized, then System REXX health checks
will not execute successfully. 
</p>
<ul>
<li>For System REXX customization activities, see "System REXX" in <cite>z/OS MVS Programming: Authorized Assembler
Services Guide</cite>.</li>
<li>For compiled REXX exec runtime availability, see "Alternate Library
for REXX Customization Considerations" in <cite>z/OS Program Directory</cite>,
or refer to product documentation accompanying IBM Library for REXX on zSeries.</li></ul>
<p>Remember that migration checks are intended to be used on your
current z/OS release and then again after you have migrated to your
new z/OS release. The steps
you might follow in each of these two scenarios are listed.</p>
<p>On your current z/OS release:</p>
<ol type="1">
<li><em>Install the latest migration checks.</em> Review all the
latest health checks (for both best practices and migration) by using
the functional PSP bucket HCHECKER (which is SMP/E FIXCAT IBM.Function.HealthChecker). If
you want to see all IBM Health
Checker for z/OS checks see <a href="http://www.ibm.com/systems/z/os/zos/hchecker/check_table.html">http://www.ibm.com/systems/z/os/zos/hchecker/check_table.html</a>. 

<p>You
might want to install the PTFs during a regular service window so
that an IPL is scheduled afterwards. Checks are often added by a function
when it is started or restarted, so you might find that installing
the PTFs before a scheduled IPL works best for you. Additional migration
checks can be added at different times, so having all the latest ones
installed before making your migration plans is recommended.</p></li>
<li><em>Activate the migration checks appropriate to your
migration path.</em> Because the naming convention for migration checks
indicates which release introduced the corresponding migration actions,
you can activate just the checks appropriate for your migration path.
Using SDSF (or another method for viewing checks, such as filters),
you can view ahead of time which migration checks you have available
on your system. For example, if you are migrating from z/OS z/OS V1R12 to z/OS V2R1 you
need to activate the migration checks for changes that occurred in
both z/OS V1R12 and z/OS V1R13. If
you are migrating from z/OS V1R13 to z/OS V2R1, you
only need to activate the migration checks for changes that occurred
in z/OS V2R1.
There are many ways to make a check active, as well as many ways of
using wildcards to include specific checks.  Here are some examples
of using the MODIFY command to make checks active: 

<ul>
<li><samp class="xph">F HZSPROC,ACTIVATE,CHECK=(IBM*,*MIG*)</samp></li>
<li><samp class="xph">F HZSPROC,ACTIVATE,CHECK=(IBM*,ICSFMIG*)</samp></li>
<li><samp class="xph">F HZSPROC,ACTIVATE,CHECK=(IBM*,ZOSMIGV2R1)</samp></li></ul>Remember that for z/OS, two naming conventions are used: one
for ICSF (that starts with ICSFMIG<span class="synph"><span class="var">nnnn</span></span>)
and one for the rest of z/OS (that starts with ZOSMIGV<span class="synph"><span class="var">vv</span></span>R<span class="synph"><span class="var">rr</span></span>).
Use a wildcard filter that includes the intended migration checks.</li>
<li><em>Review the migration check output and rerun checks as appropriate.</em> 
Any exceptions should be addressed in your migration plan.  If you
can complete the migration action before moving to the new z/OS release,
you can rerun the check to verify that it was completed correctly
on your current system.</li>
<li><em>Deactivate the migration checks if you desire.</em>  If you
no longer desire to have the migration checks active, you can deactivate
them similar to the way you activated them. For example: 

<ul>
<li><samp class="xph">F HZSPROC,DEACTIVATE,CHECK=(IBM*,*MIG*)</samp></li>
<li><samp class="xph">F HZSPROC,DEACTIVATE,CHECK=(IBM*,ICSFMIG*)</samp></li>
<li><samp class="xph">F HZSPROC,DEACTIVATE,CHECK=(IBM*,ZOSMIGV2R1)</samp></li></ul></li></ol>
<p>After you have migrated to the new z/OS version and release, the
steps are similar:</p>
<ol type="1">
<li><em>Install the latest migration checks.</em>  New migration checks
might be available for your new z/OS system
since you installed it.  Therefore, review all the latest health checks
(for both best practices and migration) by using the functional PSP
bucket HCHECKER (which is SMP/E FIXCAT IBM.Function.HealthChecker). If you want
to see <strong>all</strong> IBM Health
Checker for z/OS checks that
are available, see <a href="http://www.ibm.com/systems/z/os/zos/hchecker/check_table.html">http://www.ibm.com/systems/z/os/zos/hchecker/check_table.html</a>.</li>
<li><em>Activate the migration checks appropriate to your
migration path.</em> For migration verification, activate the checks
appropriate on the release you are migrating from, migrating through,
and migrating to. For example, if you are migrating from z/OS V1R12 to z/OS V2R1, you
need to activate the migration checks for changes that occurred in
both z/OS V1R12 and z/OS V1R13.  If
you are migrating from z/OS V1R13 to z/OS V2R1, you
only need to activate the migration checks for changes that occurred
in z/OS V2R1.
Here are some examples of using the MODIFY command to make checks
active. (These are the same activation commands shown previously.) 

<ul>
<li><samp class="xph">F HZSPROC,ACTIVATE,CHECK=(IBM*,*MIG*)</samp></li>
<li><samp class="xph">F HZSPROC,ACTIVATE,CHECK=(IBM*,ICSFMIG*)</samp></li>
<li><samp class="xph">F HZSPROC,ACTIVATE,CHECK=(IBM*,ZOSMIGV2R1)</samp></li></ul></li>
<li><em>Review the migration check output and rerun checks as appropriate.</em> 
Any exceptions, which could indicate that a migration action was not
performed correctly, should be addressed.  Rerun the check after the
corrections have been made.</li>
<li><em>Deactivate the migration checks.</em> Once your migration verification
is complete, deactivate the migration checks similar to the way you
activated them. For example (using the same deactivation commands
shown previously): 

<ul>
<li><samp class="xph">F HZSPROC,DEACTIVATE,CHECK=(IBM*,*MIG*)</samp></li>
<li><samp class="xph">F HZSPROC,DEACTIVATE,CHECK=(IBM*,ICSFMIG*)</samp></li>
<li><samp class="xph">F HZSPROC,DEACTIVATE,CHECK=(IBM*,ZOSMIGV2R1)</samp></li></ul></li></ol>
<p>Within this document, the migration actions that have checks are
clearly identified within the migration actions. All of the checks
are made by IBM Health Checker
for z/OS but, as stated earlier, some of the checks are the new migration
checks (identified by names that start with ZOSMIGV<span class="synph"><span class="var">vv</span></span>R<span class="synph"><span class="var">rr</span></span> or
ICSFMIG<span class="synph"><span class="var">nnnn</span></span>) and others are regular health
checks.</p>
<p>Note that not all migration actions in this document are addressed
by checks; many migration actions do not lend themselves to programmatic
checking. Therefore, use this document to prepare your migration plan
and do not rely solely on checks.</p>
<h2 id="zosmfloc">z/OS Management Facility</h2><a id="idx50"></a><a id="idx51"></a><a id="idx52"></a><a id="idx53"></a>
<p>IBM z/OS Management Facility (z/OSMF) provides system programmers
with a framework for managing various aspects of a z/OS system through
a web browser interface. By streamlining some traditional tasks and
automating others, z/OSMF can help to simplify the day-to-day operations
and administration of a z/OS system. For more information about z/OSMF,
see <a href="http://www.ibm.com/systems/z/os/zos/zosmf/">www.ibm.com/systems/z/os/zos/zosmf/</a>.</p>
<p>For information about z/OSMF migration steps, see "Migrating from
an earlier release of z/OSMF" in <cite>IBM z/OS Management Facility Configuration Guide</cite>.</p>
<h2 id="eafwoma">Elements and features that do not have migration actions</h2><a id="idx54"></a>
<p>The following <span>z/OS V2R1</span> elements
and features do not have migration actions and thus are not discussed: 
</p>
<ul>
<li>Alternate Library for REXX<a id="idx55"></a></li>
<li>BDT<a id="idx56"></a></li>
<li>BDT File-to-File<a id="idx57"></a></li>
<li>BDT SNA NJE<a id="idx58"></a></li>
<li>BookManager&reg; READ<a id="idx59"></a></li>
<li>Communications Server Security Level 3<a id="idx60"></a></li>
<li>EREP<a id="idx61"></a></li>
<li>ESCON&reg; Director Support<a id="idx62"></a></li>
<li>FFST<a id="idx63"></a></li>
<li>GDDM<a id="idx64"></a></li>
<li>GDDM-PGF<a id="idx65"></a></li>
<li>GDDM-REXX<a id="idx66"></a></li>
<li>HCD<a id="idx67"></a></li>
<li>HCM<a id="idx68"></a></li>
<li>HLASM Toolkit<a id="idx69"></a></li>
<li>ICKDSF<a id="idx70"></a></li>
<li>Integrated Security Services<a id="idx71"></a></li>
<li>Metal C Runtime Library<a id="idx72"></a></li>
<li>MICR/OCR<a id="idx73"></a></li>
<li>NFS<a id="idx74"></a></li>
<li>Runtime Library Extensions<a id="idx75"></a></li>
<li>SMP/E <a id="idx76"></a></li>
<li>TIOC<a id="idx77"></a></li>
<li>TSO/E<a id="idx78"></a></li>
<li>z/OS IBM TDS<a id="idx79"></a></li>
<li>z/OS Security Level 3<a id="idx80"></a></li>
<li>3270 PC File Transfer Program<a id="idx81"></a></li></ul>
<h1 id="rel2">General migration actions for everyone migrating to z/OS V2R1</h1>
<h2 id="at1ever2">Migration actions for everyone moving from z/OS V1R13</h2>
<p>This topic describes general migration actions that apply to everyone,
regardless of which elements and features you use.</p>
<h3 id="e0z3m100-gen6">Migration actions for everyone before installing z/OS V2R1</h3><a id="idx82"></a><a id="idx83"></a>
<p>This topic describes general migration actions that you can perform
on your current (old) system. You do not need the z/OS V2R1 level of code to make these changes,
and the changes do not require the z/OS V21R1 level of code to run
once they are made.</p>
<h4 id="pspbuck">Review PSP buckets</h4><a id="idx84"></a><a id="idx85"></a><a id="idx86"></a><a id="idx87"></a><a id="idx88"></a>
<p><strong>Description</strong>: You should check the preventive service planning
(PSP) &quot;buckets&quot; for important software and hardware installation
and maintenance information that occurs too late in the development
cycle to be included in the product publications. Included are PTFs
for both service and small programming enhancements (SPEs).<a id="idx89"></a></p>
<table id="pspbuck__elementorfeaturemultiple.whenchange" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Identify which PSP buckets to review. For this task you will need
to know:<a id="idx90"></a>  

<ul>
<li>PSP bucket upgrade IDs (or &quot;upgrades&quot;). The most relevant
upgrades are those related to z/OS V2R1 and its servers. The z/OS
V2R1 upgrade is ZOSV2R1; the server upgrades are shown in <a href="e0z3m100.htm#pspbuck__psptable">Table 1</a>.</li>
<li>FIXCAT values if you use the SMP/E REPORT MISSINGFIX command in
conjunction with the FIXCAT type of HOLDDATA (as mentioned in the
tip below). The FIXCAT values are shown in <a href="e0z3m100.htm#pspbuck__psptable">Table 1</a>.
Note that the values shown are for the minimum support necessary for
the servers. If you exploit additional functions on a server, the
FIXCAT value will have additional qualifiers.</li></ul> 

<table id="pspbuck__psptable" width="90%" summary="" border="1" frame="border" rules="all" class="presentation" role="presentation">
<caption><a href="e0z3m100.htm#FT_Table_1">Table 1. Servers, upgrades, and FIXCAT values</a></caption>
<thead valign="bottom">
<tr>
<th id="wq11" width="25%" align="left">Server</th>
<th id="wq12" width="25%" align="left">Upgrade</th>
<th id="wq13" width="50%" align="left">FIXCAT value</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left" headers="wq11">zBC12</td>
<td align="left" headers="wq12">2828DEVICE</td>
<td align="left" headers="wq13">IBM.Device.Server.zNext-BC-2828</td>
</tr>
<tr>
<td align="left" headers="wq11">zEC12</td>
<td align="left" headers="wq12">2827DEVICE</td>
<td align="left" headers="wq13">IBM.Device.Server.zEC12-2827</td>
</tr>
<tr>
<td align="left" headers="wq11">z114</td>
<td align="left" headers="wq12">2818DEVICE</td>
<td align="left" headers="wq13">IBM.Device.Server.z114-2818</td>
</tr>
<tr>
<td align="left" headers="wq11">z196</td>
<td align="left" headers="wq12">2817DEVICE</td>
<td align="left" headers="wq13">IBM.Device.Server.z196-2817</td>
</tr>
<tr>
<td align="left" headers="wq11">z10 EC</td>
<td align="left" headers="wq12">2097DEVICE</td>
<td align="left" headers="wq13">IBM.Device.Server.z10-EC-2097</td>
</tr>
<tr>
<td align="left" headers="wq11">z10 BC</td>
<td align="left" headers="wq12">2098DEVICE</td>
<td align="left" headers="wq13">IBM.Device.Server.z10-BC-2098</td>
</tr>
<tr>
<td align="left" headers="wq11">z9 EC</td>
<td align="left" headers="wq12">2094DEVICE</td>
<td align="left" headers="wq13">IBM.Device.Server.z9-EC-2094</td>
</tr>
<tr>
<td align="left" headers="wq11">z9 BC</td>
<td align="left" headers="wq12">2096DEVICE</td>
<td align="left" headers="wq13">IBM.Device.Server.z9-BC-2096</td>
</tr>
</tbody>
</table></li>
<li>Obtain the PSP buckets from <a href="http://www14.software.ibm.com/webapp/set2/psp/srchBroker">http://www14.software.ibm.com/webapp/set2/psp/srchBroker</a> or
from IBMLink.<a id="idx91"></a><a id="idx92"></a><a id="idx93"></a></li>
<li>Review the PSP buckets and take whatever actions are prescribed.</li></ol>
<p><strong>Tip</strong>: To simplify finding the appropriate PSP bucket and
identifying which PTFs listed in the PSP bucket need to be installed
on your system, you can use SMP/E FIXCATs and the REPORT MISSINGFIX
command. (The FIXCAT values are shown in <a href="e0z3m100.htm#pspbuck__elementorfeaturemultiple.whenchange">Table 0</a>.)</p>
<p><strong>Reference information</strong>: 
</p>
<ul>
<li> For z/OS subsets, see <cite>z/OS Program Directory</cite>.</li>
<li>For details about the SMP/E REPORT MISSINGFIX command, see <cite>SMP/E for z/OS Commands</cite>.</li></ul>
<h4 id="coxptfs">Install coexistence and fallback PTFs</h4>
<p><strong>Description</strong>: Coexistence and fallback PTFs installed on
pre-z/OS V2R1 systems allow those systems to coexist with z/OS V2R1
systems during your migration, and allow backout from z/OS V2R1 to
the previous systems if necessary. Coexistence and fallback are important
because they allow you to migrate systems in a multisystem configuration
to z/OS V2R1 using rolling IPLs (one system at a time), allowing for
continuous application availability.</p>
<table id="wq14" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx94"></a><strong>Element
or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>Install the appropriate PTFs.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Before introducing z/OS V2R1 into your environment, install coexistence
and fallback PTFs on all pre-z/OS V2R1 systems with which your z/OS
V2R1 system will coexist.</p>
<p> Use the SMP/E REPORT MISSINGFIX command in conjunction with the
FIXCAT type of HOLDDATA as follows:</p>
<ol type="1">
<li>Acquire and RECEIVE the latest HOLDDATA onto your pre-z/OS V2R1
systems. Use your normal service acquisition portals or download the
HOLDDATA directly from  <a href="http://service.software.ibm.com/holdata/390holddata.html">http://service.software.ibm.com/holdata/390holddata.html</a>.
Ensure that you select <strong>Full</strong> from the Download NOW column to
receive the FIXCAT HOLDDATA, as the other files do not contain FIXCATs.</li>
<li>Run the SMP/E REPORT MISSINGFIX command on your pre-z/OS
V2R1 systems and specify a Fix Category (FIXCAT) value of &quot;IBM.Coexistence.z/OS.V2R1&quot;. The
report will identify any missing coexistence and fallback PTFs for
that system. For complete information about the REPORT MISSINGFIX
command, see <cite>SMP/E for z/OS Commands</cite>.</li>
<li>Periodically, you might want to acquire the latest HOLDDATA and
rerun the REPORT MISSINGFIX command to find out if there are any new
coexistence and fallback PTFs.</li></ol>
<p>REVIEWERS: I received the following sysplex APAR info
via service items. I'm not sure we are so explicit about the detail
of APARs and PTFs so I will defer to Marna for comments on these additions.</p>
<div>
<div class="note-noindent" id="wq16">
<span class="notetitle">Note:</span> <span class="notebody">Before installing z/OS V2R1 into an existing sysplex
that contains one or more lower level releases, you must ensure the
following that the following APARs are installed and active on all
the lower level systems in the sysplex:

<ul>
<li>APAR OA37604 with the following PTFs:

<ul>
<li>UA68465</li>
<li>UA68466</li>
<li>UA68467</li>
<li>UA68468)</li></ul></li>
<li>APAR OA39287 with the following PTFs:

<ul>
<li>UA68581</li>
<li>UA68582)</li></ul></li>
<li>APAR OA40259 with the following PTFs: 

<ul>
<li>UA68825</li>
<li>UA68826</li></ul></li>
<li>APAR OA40504 with the following PTFs:

<ul>
<li>UA68264</li>
<li>UA68265</li>
<li>UA68266</li>
<li>US68267</li></ul></li>
<li>APAR OA40957 with the following PTFs:

<ul>
<li>UA68448</li>
<li>UA68449</li>
<li>UA68450</li>
<li>UA68451</li></ul>The PTFs MUST also be installed on any other z/OS systems that
use Network Authentication Services for z/OS (Kerberos) to communicate
with systems running z/OS V2R1 or systems with the PTFs for APAR OA40957
applied.</li>
<li>APAR OA41430 with the following PTFs:

<ul>
<li>HBB7750 UA68483</li>
<li>HBB7760 UA68484</li>
<li>HBB7770 UA68485</li>
<li>HBB7780 UA68486</li></ul></li></ul></span></div></div>
<p><strong>Reference information</strong>: For an explanation of the z/OS coexistence-migration-fallback
policy, see the  topic
in <cite>z/OS Planning
for Installation</cite>.</p>
<h4 id="at3sofc">Use zSoftCap to identify the effect of capacity changes</h4>
<p>[[[[ Technical contact: James Shaw/Gaithersburg/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: The zSoftware Migration Capacity
Planning Aid (zSoftCap) is a PC-based tool that evaluates the effects
of  software release migrations. <a id="idx95"></a><a id="idx96"></a><a id="idx97"></a><a id="idx98"></a><a id="idx99"></a></p>
<table id="wq17" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to help in assessing processor
capacity and available resources when migrating to new software levels.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>This
tool runs on your workstation. Requirements are: 


<ul>
<li>A dual-core technology, or faster, processor.</li>
<li>An SVGA display 1024 x 768 or better.</li>
<li>Approximately 5 MB of hard disk space for the zSoftCap application
and user's guide, plus 80 MB for the IBM Java 1.6 runtime environment.</li></ul>


<p></p></td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>This tool runs on your workstation. Requirements
are:


<ul>
<li>Windows 7 or Windows XP.</li>
<li>IBM Java&trade; 1.6, or later, runtime environment.
This environment is available with the tool.</li></ul></td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 

</p>
<ul>
<li>Download zSoftCap from one of the following web sites:<a id="idx100"></a><a id="idx101"></a><a id="idx102"></a>



<ul>
<li>Customers: <a href="http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS268">http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS268</a>.</li>
<li>Business partners: <a href="http://www-03.ibm.com/partnerworld/partnerinfo/src/atsmastr.nsf/WebIndex/PRS1762">http://partners.boulder.ibm.com/src/atsmastr.nsf/Web/Techdocs</a>.
Note that this requires an ID on PartnerWorld&reg;.</li></ul></li>
<li>Run zSoftCap to determine your expected increase in CPU utilization
(if any) and to identify your storage requirements, such as how much
storage is needed to IPL.</li></ul>
<p><strong>Reference information</strong>: <cite>zSoftCap User's Guide</cite>, which is provided with the tool.</p>
<h4 id="zrodasd">Add or change volumes to keep your z/OS root file system in a single data set</h4>
<p>[[[[ Contributor: Marna Walle/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: Because of release enhancements and
service, the size of the z/OS root file system (or &quot;version root
file system&quot;) continues to grow from release to release. The size
of the z/OS root file system, whether HFS or zFS, is expected to closely
approach, if not exceed, the limit of 3339 cylinders on a 3390-3 device. <a id="idx103"></a><a id="idx104"></a><a id="idx105"></a></p>
<p>It is advisable to have the z/OS root file system within a single
data set for ease of management.</p>
<table id="wq18" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended for ease of management if
your z/OS root file system resides on a 3390-3 volume (or another
DASD volume that is close to the 3390-3 limit of 3339 cylinders).</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>Use IBM Health
Checker for z/OS check CHECK(IBMUSS, ZOSMIGREC_ROOT_FS_SIZE) to determine
if a volume has enough space for the z/OS root file system.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: To keep the z/OS root
file system in a single data set, do one of the following: 
</p>
<ul>
<li>Move your z/OS root file system to a larger DASD volume geometry.</li>
<li>Use multiple volumes for the z/OS root file system data set.</li></ul>
<p>If your z/OS root data set cannot fit on the volume or volumes
you have defined for it, divide the z/OS root, with the smaller file
systems being managed together.</p>
<p>Remember that all systems to which you deploy the z/OS root file system need sufficient DASD space
to hold the z/OS root.</p>
<p><strong>Tip</strong>:  
</p>
<ul>
<li>File systems for subsystems and products other than the z/OS product itself might also
increase in size. When examining the volume for how much space your z/OS file system is using, check
other product file system sizes too.</li></ul>
<p><strong>Reference information</strong>: For more information about multivolume
data sets, see <cite>z/OS DFSMS Implementing System-Managed Storage</cite>.</p>
<h4 id="vxcfgps">Verify that you have enough XCF groups in your CDS and enough
XCF members in your XCF groups</h4><a id="idx106"></a>
<p><strong>Description</strong>: Over time, as various z/OS functions and applications
exploit XCF services, you must ensure that there is enough space in
the sysplex couple data set for all the XCF groups and members that
are to be defined by the exploiters. It is possible that your sysplex
couple data set could contain an inadequate number of XCF groups or
members.</p>
<div>
<div class="note-noindent" id="wq19">
<span class="notetitle">Note:</span> <span class="notebody">Starting with z/OS V1R13,  JES2 is using new XCF groups
for its spool migration enhancement. JES spool migration utilizes
tasks on all members of a MAS to manage the migration of a spool volume's
data and the access to that migrating or migrated data. These various
tasks communicate using messages sent through JESXCF services. The
JESXCF services utilize one XCF group for each active migration to
identify what messages are for which active migration. XCF groups
are a limited system resource, so JES2 limits the number of concurrent
active migrations to five. If you plan to  perform spool migrations,
verify that you have up to five XCF groups available if  you intend
to have up to five spool migrations active at any given time. JES2
will only utilize the number of XCF groups available, up to five,
for spool migrations.</span></div></div>
<table id="wq20" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to ensure that you have
an adequate number of XCF groups and members formatted in your sysplex
couple data sets.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>Use IBM Health
Checker for z/OS check XCF_SYSPLEX_CDS_CAPACITY, which checks the
adequacy of the number of groups, members, and systems for which a
sysplex CDS is formatted.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Issue the DISPLAY XCF,COUPLE command on your current system. Notice
the values of MAXGROUP and PEAK for your sysplex couple data sets.
These values show you the maximum number of XCF groups that the couple
data sets can support, and the peak number of XCF groups ever in use
in the sysplex. Also notice the values of MAXMEMBER and PEAK for your
sysplex couple data sets. These values show you the maximum number
of members that the couple data set can support in one group, and
the greatest number of members ever in use in the largest group in
the sysplex.</li>
<li>If your peak member value is close to the maximum member value,
you might want to reformat your sysplex couple data sets to support
a larger maximum number of members to be used by any one group.</li></ol>
<p><strong>Reference information</strong>: 

</p>
<ul>
<li>For information about formatting sysplex couple data sets with
the MAXGROUP and MAXMEMBER parameters, see <cite>z/OS MVS Setting Up a Sysplex</cite>.</li>
<li>For information about the DISPLAY XCF command, see <cite>z/OS MVS System Commands</cite>.</li></ul>
<h4 id="xfmtmark-gen1">Ensure your CustomPac Installation Dialog is updated</h4><a id="idx107"></a>
<p>Ed
Ghiazza: placeholder for general CustomPak migration actions</p>
<p></p>
<p><strong>Description</strong>: As of z/OS V2R1 ServerPac is making
changes that require you to use an updated RECEIVE job. As of z/OS
V2R1 you must update the CustomPac Installation Dialog to level 26.00.00
or higher in order to support Secure FTP (FTP using Secure Sockets
Layer or FTPS) and removal of the BookManager format of the IYO. 
You can determine the level of the CustomPac Installation Dialog you
are using by checking the upper right hand corner of the primary panel
CPPPPOLI.</p>
<p></p>
<p>IBM plans to remove support for unsecured FTP connections used
for z/OS software and service delivery October 1, 2013. At that time,
it is planned that new System z software (products and service) downloads
will require the use of FTPS or Download Director with encryption.
You will be able to download orders created before October 1, 2013,
using any currently supported method until they expire, or until November
1, 2013, when IBM plans to refuse unsecured FTP connections to the
IBM servers used for System z software downloads.</p>
<p> If you plan to use FTPS, IBM recommends that you visit the Connectivity
Test website to verify your system setup well in advance. No change
is required for Download Director with encryption; however, you can
also verify Download Director with the Connectivity Test. The Connectivity
Test can be found at the following web site: <a href="./common-wwwsym.html">https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang=en_US&amp;source=cbct</a></p>
<p>If you use the &quot;Receive an Order from an FTP Server&quot; path in your
existing CustomPac Installation Dialog to download a ServerPac or
CustomPac Internet delivery order on or after October 1, 2013, you
will need to run a job to update your dialog to level 26.00.00 or
higher. This action |ensures that the RECEIVE job JCL is generated
with Secure FTP statements and no longer references the Bookmanager
file of the Installing Your Order (IYO) document.  The document <em>Installing
Your Order (IYO)</em> is no longer available in BookManager format. </p>
<div>
<div class="note-noindent" id="wq22">
<span class="notetitle">Note:</span> <span class="notebody">In
releases before z/OS V2R1 the RECEIVE job references the BookManager
version of the IYO; therefore, you must update the dialog level to
level 26.00.00 or higher before receiving your order.</span></div></div>
<table id="wq23" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Customized Offerings for z/OS</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action. The change is introduced
with z/OS V2R1 as of October 1, 2013; however, it also applies to
z/OS V1R13 as long as that release remains orderable.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your existing CustomPac Dialog is not
at level 26.00.00 or higher you will need to install the latest dialog.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<table width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>See  &quot;Identifying driving system software requirements
for installing z/OS using ServerPac or dump-by-data-set SystemPac&quot;
in <cite>z/OS Planning
for Installation</cite></td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>Failure to update the CustomPac Installation
Dialog to the latest level (26.00.00) results in the RECEIVE job failing.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<p>For <strong>ServerPac customers</strong>, see the topic &quot;Updating
your dialogs&quot;  in <cite class="dtm2iddpdfbook">ServerPac: Using the Installation Dialog</cite>.<a href="../com.ibm.zos.r21.gima200/gima200.htm">../com.ibm.zos.r21.gima200/gima200.htm</a>  You will need to refer to the
section for your order's delivery media (that is, tape, DVD, or internet
delivery) to determine the steps to take.</p>
<p>For <strong>CustomPac customers</strong>, see the topic
&quot;Updating your dialogs&quot; in <cite class="dtm2iddpdfbook">CustomPac:
Using the Installation Dialog</cite>. You will need to refer to the
section for your order's delivery media (that is, tape, DVD, or internet
delivery) to determine the steps to take.</p>
<p><strong>Reference information:</strong> 
</p>
<ul>
<li>For more information about the IBM direction to only support Secure
FTP for downloading Customized Offerings Internet Delivery orders
from IBM Servers, see <cite>z/OS V2R1 Preview  Announcement</cite></li>
<li>For more information about the internet delivery method to choose
for downloading your ServerPac or CustomPac (SystemPac, ProductPac,
FunctionPac) Internet Delivery order, see &quot;Choosing the Internet download
method: direct or intermediate&quot; in z/OS Planning
for Installation.</li>
<li>For ServerPac customers who want more information about updating
your CustomPac Installation Dialog, see &quot;Updating Your Dialogs&quot; in <cite>ServerPac:
Using the Installation Dialog</cite>.</li>
<li>For ServerPac customers who want more information about receiving
an order from a server using the CustomPac Installation Dialog, see
&quot;Receiving an Order from an FTP Server&quot; in <cite>ServerPac: Using
the Installation Dialog</cite>.</li>
<li>For CustomPac customers who want more information about updating
your CustomPac Installation Dialog, see &quot;Updating Your Dialogs&quot; in <cite>CustomPac:
Installation Dialog Reference Manual</cite>.</li>
<li>For CustomPac customers who want more information about receiving
an order from a server using the CustomPac Installation Dialog, see
&quot;Receiving an Order from an FTP Server&quot; in <cite>CustomPac: Installation
Dialog Reference Manual</cite>.</li>
<li>See the README and Checklist documents on the Shopz download pages
for your order.</li></ul>
<h3 id="e0z3m100-gen7">Migration actions for everyone before the first IPL of z/OS
V2R1</h3>
<p>This topic describes general migration actions that you can perform
after you have installed z/OS V1R13 but before the first time you
IPL. These actions might require the z/OS V1R13
level of code to be installed but do not require it to be active.</p>
<h4 id="verify_ifaprd">Verify your IFAPRDxx Product ID is correct for z/OS Version
2</h4><a id="idx108"></a>
<p></p>
<p>[[[[ Writer: Jim Guilianelli/Poughkeepsie/IBM
@IBMUS ]]]] [[[[ Technical contact: Manu Prasad/India/IBM@IBMIN ]]]]</p>
<p><strong>Description</strong>:  Because z/OS has changed from Version 1 (V1)
to Version 2 (V2), the IFAPRDxx parmlib member Product ID should reflect
the new program number for z/OS. The <samp class="xph">Feature</samp>, <samp class="xph">Release</samp>,
and <samp class="xph">Modification</samp> values also found in IFAPRDxx should
be specified as "*", so those values do not have to change; only the <samp class="xph">Product
ID</samp> is affected by this change.</p>
<table id="wq24" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>General migration action not tied to a specific
release..</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>If you are sharing the IFAPRDxx parmlib member
between z/OS V1 and V2 systems, keep the V1 Product ID statements
(for 5694-A01). You can have both the V1 Product ID and the V2 Product
ID statements in the same IFAPRDxx parmlib member. After you have
completed your migration to z/OS V2, you can remove the V1 Product
ID statement from your IFAPRDxx parmlib member.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>Failure to update IFAPRDxx with the correct
Product ID statement for z/OS V2 will result in various initialization
failures. An example of one of these failures is the following: 
<pre class="xmp"><code>IFA104I REGISTRATION HAS BEEN 
DENIED FOR PRODUCT 
WITH OWNER=IBM CORP NAME=z/OS
FEATURE=TCP/IP BASE 
VERSION=.. ID=5650-ZOS</code></pre></td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ul>
<li>If you use ServerPac, the customized IFAPRDxx parmlib member has
been shipped to you in CPAC.PARMLIB. Verify that you are either using
that parmlib member, or have copied its contents to a parmlib member
you are using.</li>
<li> If you are using CBPDO, use provided job ZOSREG in the RIMLIB,
to place a customized IFAPRD00 member into your parmlib. 
<div>
<div class="note-noindent" id="wq25">
<span class="notetitle">Note:</span> <span class="notebody">Customers
must ensure that the policy in IFAPRDxx enables only the version/release
at which they are licensed. Use of and enablement of z/OS features
is subject to the z/OS license terms and conditions and must be done
with the knowledge of your asset manager according to the terms and
conditions for z/OS. For additional license terms and conditions,
see the "Usage Restriction" section of the <cite>z/OS Licensed Program
Specifications</cite> .</span></div></div></li></ul>
<p><strong>Reference information:</strong> 
</p>
<ul>
<li><cite>z/OS MVS Initialization and Tuning Reference</cite></li>
<li><cite>z/OS Planning
for Installation</cite></li>
<li><cite>z/OS Program Directory</cite></li></ul>
<h4 id="at3gena">Set up an IPCS environment</h4><a id="idx109"></a><a id="idx110"></a><a id="idx111"></a><a id="idx112"></a><a id="idx113"></a><a id="idx114"></a><a id="idx115"></a>
<p>[[[[ Technical contact: Purvi Patel/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: The interactive problem control system (IPCS)
is a tool in the BCP that provides formatting and analysis support
for dumps and traces. You must set up an IPCS environment so that
you can process any dumps taken on the newly-built z/OS system.<a id="idx116"></a></p>
<table id="wq26" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the target system cannot be used for
native IPCS and usage of IPCS for information produced by the target
system is necessary.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td> 

<p><strong>Target system software requirements</strong>:</p></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>The version and release level of IPCS
must match the level of the system that produced the dump. You must
use the z/OS MVS libraries of IPCS code, for example, to analyze a
dump or trace produced by that level of the z/OS MVS system.  

<p><strong>Tip</strong>:
If it is necessary to have unique IPCS data set names for your current
system (because you already have the IPCS data sets with similar names
on your earlier system), you can create a unique alias in your catalog
that resolves to the current IPCS data sets. This will allow you to
have &quot;duplicately&quot;-named IPCS data sets, which are uniquely referenced.</p> 

<p>When
using unique aliases, remember that you might have to update the security
definition for the unique high-level qualifier used in the catalog.</p></td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Set up an IPCS environment. For guidance,
use the information listed in &quot;Reference information&quot; below.
During setup, ensure that your logon procedure points to the target
system's level of IPCS data sets, which are shown in <a href="e0z3m100.htm#at3gena__ipcsdsc">Table 2</a>.</p>
<div>
<div class="note-noindent" id="wq27">
<span class="notetitle">Note:</span> <span class="notebody">z/OS V1R13 GTF data cannot be properly formatted on a pre-z/OS
V1R13 system. If you attempt to format z/OS V1R13 GTF data with IPCS
on a pre-z/OS V1R13 system, the fields will be unusable. Also note
that pre-z/OS V1R13 GTF data cannot be properly formatted on a z/OS
V1R13 system. You must use z/OS V1R13 IPCS for z/OS V1R13 GTF data
and pre-z/OS V1R13 IPCS for pre-z/OS V1R13 GTF data. You cannot merge
pre-z/OS V1R13 GTF data with z/OS V1R13 GTF data and expect to format
it on any z/OS release. Plan on using the IPCS level associated with
the GTF data that you collect.</span></div></div>
<table id="at3gena__ipcsdsc" width="100%" summary="" border="1" frame="border" rules="all">
<caption><a href="e0z3m100.htm#FT_Table_2">Table 2. IPCS data set requirements for a logon procedure or DD name allocation</a></caption>
<thead valign="bottom">
<tr>
<th id="wq28" align="left" valign="bottom">DD name</th>
<th id="wq29" align="left" valign="bottom">Data set name</th>
<th id="wq30" align="left" valign="bottom">Notes&reg;</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq28">IATTABL</td>
<td headers="wq29">SYS1.SIATTBL0, if applicable</td>
<td headers="wq30">This is a JES3 data set. If you use JES3, ensure
that this data set corresponds to the level of JES3 that you are running
with z/OS V1R13 or higher.</td>
</tr>
<tr>
<td headers="wq28">IPCSPARM 

<p> </p>
<div>
<div class="note-noindent" id="wq31">
<span class="notetitle">Note:</span> <span class="notebody">This DD name is needed if
one of the following is true: 

<ul>
<li>The system on which the dump was taken has different BCP and JES
levels than the system on which the dump will be examined using IPCS.</li>
<li>You have not specified these data sets in your system's parmlib
concatenation.</li></ul></span></div></div></td>
<td headers="wq29">SYS1.PARMLIB</td>
<td headers="wq30">This is the data set that contains all the shipped z/OS V2R1 parmlib IPCS members.
If the copies of BLSCECT and all the other IPCS members are not at z/OS V2R1 level, then IPCS might
fail when you attempt to use it.</td>
</tr>
<tr>
<td headers="wq28">IPCSPARM</td>
<td headers="wq29">SYS1.SHASPARM, if applicable</td>
<td headers="wq30">This is a JES2 data set. If you use JES2, ensure
that this data set corresponds to the level of JES2 that you are running
with z/OS V1R13 or higher.</td>
</tr>
<tr>
<td headers="wq28"><a id="idx117"></a><a id="idx118"></a>IPCSPARM</td>
<td headers="wq29">SYS1.SIATPARM, if applicable</td>
<td headers="wq30">This is a JES3 data set. If you use JES3, ensure
that this data set corresponds to the level of JES3 that you are running
with z/OS V1R13 or higher.</td>
</tr>
<tr>
<td headers="wq28">ISPMLIB</td>
<td headers="wq29">SYS1.SBLSMSG0</td>
<td headers="wq30"></td>
</tr>
<tr>
<td headers="wq28">ISPMLIB</td>
<td headers="wq29">SYS1.SIATMSG0, if applicable</td>
<td headers="wq30">This is a JES3 data set. If you use JES3, ensure
that this data set corresponds to the level of JES3 that you are running
with z/OS V1R13 or higher.</td>
</tr>
<tr>
<td headers="wq28">ISPPLIB</td>
<td headers="wq29">SYS1.SBLSPNL0</td>
<td headers="wq30"></td>
</tr>
<tr>
<td headers="wq28">ISPPLIB</td>
<td headers="wq29">SYS1.SHASPNL0, if applicable</td>
<td headers="wq30">This is a JES2 data set. If you use JES2, ensure
that this data set corresponds to the level of JES2 that you are running
with z/OS V1R13 or higher.</td>
</tr>
<tr>
<td headers="wq28">ISPPLIB</td>
<td headers="wq29">SYS1.SIATPNL0, if applicable</td>
<td headers="wq30">This is a JES3 data set. If you use JES3, ensure
that this data set corresponds to the level of JES3 that you are running
with z/OS V1R13 or higher.</td>
</tr>
<tr>
<td headers="wq28">ISPSLIB</td>
<td headers="wq29">SYS1.SBLSKEL0</td>
<td headers="wq30"></td>
</tr>
<tr>
<td headers="wq28">ISPTLIB</td>
<td headers="wq29">SYS1.SBLSTBL0</td>
<td headers="wq30"></td>
</tr>
<tr>
<td headers="wq28">STEPLIB 

<p> </p>
<div>
<div class="note-noindent" id="wq32">
<span class="notetitle">Note:</span> <span class="notebody">This DD name is needed if
the system on which the dump was taken has different BCP and JES levels
than the system on which the dump will be examined using IPCS.</span></div></div></td>
<td headers="wq29">SYS1.MIGLIB</td>
<td headers="wq30"></td>
</tr>
<tr>
<td headers="wq28">STEPLIB</td>
<td headers="wq29">SYS1.SIEAMIGE</td>
<td headers="wq30">This data set was added in z/OS V1R7. It is a PDSE data set that complements
SYS1.MIGLIB. This data set is used along with SYS1.MIGLIB for IPCS.</td>
</tr>
<tr>
<td headers="wq28">STEPLIB</td>
<td headers="wq29">SYS1.SHASMIG, if applicable</td>
<td headers="wq30">This is a JES2 data set. If you use JES2, ensure
that this data set corresponds to the level of JES2 that you are running
with z/OS V1R13 or higher.</td>
</tr>
<tr>
<td headers="wq28">STEPLIB</td>
<td headers="wq29">SYS1.SIATMIG, if applicable</td>
<td headers="wq30">This is a JES3 data set. If you use JES3, ensure
that this data set corresponds to the level of JES3 that you are running
with z/OS V1R13 or higher.</td>
</tr>
<tr>
<td headers="wq28">SYSEXEC</td>
<td headers="wq29">SYS1.SIATCLI0, if applicable</td>
<td headers="wq30">This is a JES3 data set. If you use JES3, ensure
that this data set corresponds to the level of JES3 that you are running
with z/OS V1R13 or higher.</td>
</tr>
<tr>
<td headers="wq28">SYSPROC</td>
<td headers="wq29">SYS1.SBLSCLI0</td>
<td headers="wq30"></td>
</tr>
</tbody>
</table>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li>For more information about IPCS, see <cite>z/OS MVS IPCS Customization</cite>.</li>
<li>For more information about the correct logon procedure updates,
see the <cite>z/OS Program Directory</cite>.</li>
<li>For information about setting up the JES2 IPCS environment, see <cite>z/OS JES2 Diagnosis</cite>.</li>
<li>For information about setting up the JES3 IPCS environment, see <cite>z/OS JES3 Diagnosis</cite>.</li>
<li>For information about running different levels o IPCS, see "Running
Different Levels of IPCS " in <cite>z/OS MVS IPCS User&amp;apos;s Guide</cite>.</li>
<li> For additional information, see <cite>z/OS Communications Server: IP Diagnosis Guide</cite>.</li></ul>
<h4 id="at3genb">Use IBM-supplied parmlib and proclib members</h4>
<p><strong>Description</strong>: Ensure that all new and changed
parmlib and proclib members that are shipped in z/OS V2R1 are updated in your parmlib and proclib
concatenations.<a id="idx119"></a><a id="idx120"></a><a id="idx121"></a><a id="idx122"></a></p>
<table id="wq33" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ul>
<li>For parmlib, add the data set pointed to by the z/OS V2R1 PARMLIB DDDEF to your parmlib concatenation.
The data set should generally be added last in the concatenation,
and you should make sure that the other data sets in the concatenation
do not have members with the same names as IBM-supplied members. If
you place the data set on the system residence volume and use an indirect
catalog entry, future migrations will not require this particular
migration step.</li>
<li>For proclib:


<ol type="1">
<li>Ensure that the default proclib members have been copied to your
default proclib to pick up the new and changed members.</li>
<li>Update individual sample members provided and ensure they are
accessible to the system, as shown in the table of proclib member
updates in <cite>z/OS Program Directory</cite>.</li>
<li>Ensure that the procedure libraries listed in the table of libraries
to be added to the proclib concatenation in <cite>z/OS Program Directory</cite> have
been placed in the necessary procedure library concatenations and
are available to the system.</li></ol></li></ul>
<p><strong>Reference information</strong>: For lists of parmlib
and proclib members that are shipped, see <cite>z/OS Program Directory</cite>.</p>
<h4 id="at3gend">Migrate /etc and /var system control files</h4>
<p><strong>Description</strong>: The <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> directories
contain system control files. <a id="idx123"></a><a id="idx124"></a>
The <samp class="xph">/etc</samp> directory contains customization
data that you maintain and the <samp class="xph">/var</samp> directory contains
customization data that IBM maintains.</p>
<p> The following elements and features use <samp class="xph">/etc</samp>: 

</p>
<ul>
<li>BCP (Predictive Failure Analysis).</li>
<li>CIM.</li>
<li>Communications Server (IP Services component). See <a href="e0z3m100.htm#upcsetc">IP Services: Update /etc configuration files</a>.</li>
<li>Cryptographic Services (PKI Services and System SSL components).</li>
<li>DFSMSrmm.</li>
<li>Distributed File Service. The SMB server uses <samp class="xph">/etc/dfs</samp>.</li>
<li>IBM HTTP Server.</li>
<li>z/OS IBM TDS (LDAP server
component) <samp class="xph">uses /etc/ldap</samp>.</li>
<li>Infoprint Server. See <a href="./ai3svco.html">Remount the Printer Inventory and copy files that were customized</a>.</li>
<li>Library Server. See <a href="e0z3m100.htm#libsb1i">Library Server actions to perform before the first IPL of z/OS
V2R1</a>.</li>
<li>z/OS UNIX.</li></ul>
<p> The following elements and features use <samp class="xph">/var</samp>: 

</p>
<ul>
<li>Cryptographic Services (OCSF component). See <a href="e0z3m100.htm#ae3ois">OCSF: Migrate the directory structure</a>.</li>
<li>DFSMSrmm.</li>
<li>z/OS IBM TDS (LDAP server
component) uses <samp class="xph">/var/ldap</samp>.</li>
<li>Infoprint Server. See <a href="./ai3svco.html">Remount the Printer Inventory and copy files that were customized</a>.</li>
<li>Integrated Security Services. The Network Authentication Service
component uses <samp class="xph">/var/skrb</samp>.</li></ul>
<p>During installation, subdirectories of <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> are
created. If you install z/OS using ServerPac or SystemPac&reg;, some files are loaded into <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> because
of the customization performed in ServerPac and SystemPac. You have to merge the files in <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> with
those on your previous system. If you install z/OS using CBPDO, you should copy the files from
your old system to the z/OS V2R1 <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> subdirectories.</p>
<p>After merging or copying the contents of <samp class="xph">/etc</samp> and <samp class="xph">/var</samp>,
you have to inspect and modify the files as necessary to reflect z/OS V2R1 requirements.</p>
<table id="wq35" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Copy files from your old system
to the z/OS V2R1 <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> subdirectories,
and then modify the files as necessary to reflect z/OS V2R1 requirements. If you have other files
under your existing <samp class="xph">/var</samp> directory, then you will have
to merge the old and new files under <samp class="xph">/var</samp>. The easiest
way to do this is to create a clone of your current <samp class="xph">/var</samp> file
system and then copy the new <samp class="xph">/var</samp> files into the clone.</p>
<p>Many z/OS UNIX utilities
are available for comparing and copying directory structures and files.
Two that are especially helpful for <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> migration
work are: 

</p>
<ul>
<li><strong>diff</strong> (with the <strong>-r</strong> option,
for recursion): This utility is very useful for comparing the path
structures and file contents, and has many options available. The <strong>dircmp</strong> utility has fewer options for directory comparisons,
and the <strong>cmp</strong> utility stops after the first difference
in a file comparison and has output that is more cumbersome.</li>
<li><strong>pax</strong>: The <strong>-rw</strong> option
works like a copy (instead of making or extracting from a single file
archive) for directories, symbolic links, and files. Consider the <strong>-pe</strong> option for saving the attributes when doing
the copy. The <strong>-k</strong> option prevents overwriting
of existing files.</li></ul>
<p>To determine what you need to migrate, first compare the ServerPac's <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> file
systems with your existing <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> file
systems. Mount a copy of your existing <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> file
systems to a location outside the ServerPac file system. For instance,
you might have your ServerPac file systems at <samp class="xph">/ServerPac/zOS_Rx/etc</samp> and <samp class="xph">/ServerPac/zOS_Rx/var</samp>,
and your existing file systems at <samp class="xph">/Service/ImageX/etc</samp> and <samp class="xph">/Service/ImageX/var</samp>.
You might have several file systems to mount that are copies of each
of your image's <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> file systems (ImageX,
ImageY, and ImageZ, for instance). To compare the ServerPac and existing
system's <samp class="xph">/etc</samp> and <samp class="xph">/var</samp>, you can run two z/OS UNIX commands,
such as: 
</p>
<pre class="xmp"><code>diff  -r  /ServerPac/zOS_Rx/etc  /Service/ImageX/etc
diff  -r  /ServerPac/zOS_Rx/var  /Service/ImageX/var</code></pre><p class="indatacontent">
These command
results will give you a list of the changes that your existing system's <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> file
systems are missing--both the structure differences and the file
content differences.</p>
<p>Once you know the directories, symbolic links, and files you are
missing from your existing system, there are several ways to propagate
the ServerPac information forward: 

</p>
<ul>
<li>You could use the <strong>pax</strong> command (with the <strong>-k</strong> option) to copy from the ServerPac <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> file
systems to each of your existing system's <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> file
systems. For example:

<pre class="xmp"><code>cd /ServerPac/zOS_Rx/etc
pax -rvwk -pe * /Service/ImageX/etc</code></pre>
Another example:

<pre class="xmp"><code>cd /ServerPac/zOS_Rx/var
pax -rvwk -pe * /Service/ImageX/var</code></pre>
The <strong>pax</strong> command
is a good choice because it copies all files, directories, and symbolic
links for each file system from the ServerPac system using a single
command without overlaying any existing files.</li>
<li>You could rerun the product-supplied MKDIR jobs to recreate the
directories and symbolic links on each of your existing system's <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> file
systems. (A list of the MKDIR jobs is found in <cite>z/OS Program Directory</cite> and
the other program directories for the products that were in your ServerPac
order.) MKDIR jobs are designed to be run multiple times without damaging
your existing file system. For the files under <samp class="xph">/var/ocsf</samp>,
rerun the OCSF-supplied <samp class="xph">ocsf_install_crypto</samp> installation
script. Or, you can combine these jobs and script them into a single
batch job to make the execution more consolidated and repeatable.</li></ul>
<p>After you have made the changes to a copy of your existing image's <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> file
systems, you can unmount them and use them for your deployment of
the ServerPac system, as your schedule indicates. Remember, you are
using <em>copies</em> of your existing <samp class="xph">/etc</samp> and <samp class="xph">/var</samp> file
systems, and you are <em>preserving</em> what you had
previously by modifying copies, so your customization for those specific
existing images is not lost.</p>
<p><strong>Reference information</strong>: None.</p>
<h4 id="automsg">Update automation and procedures for changed and deleted messages</h4>
<p><strong>Description</strong>: Every release, many messages change and some
are deleted. If you use automation programs to handle messages, or
you have operator or other procedures that deal with messages, you
should update the programs or procedures appropriately.</p>
<table id="wq36" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx125"></a><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use automation programs or other
procedures to handle messages.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Review the lists of changed and deleted messages
at  in <cite>z/OS Summary of Message and Interface Changes</cite>.
Update programs that automate on these messages and make other necessary
accommodations.</p>
<p>Also, see the following migration actions, which have greater detail
about some of the message changes: 
</p>
<ul>
<li><a href="./dfsomsg.html">Update automation for changed DFSORT messages</a></li>
<li><a href="e0z3m100.htm#btemode">Migrate from IP PrintWay basic
mode to extended mode</a></li>
<li><a href="e0z3m100.htm#dlogsplit1">Modify code that depends on the format of suppressed split
messages in the DLOG</a></li>
<li><a href="e0z3m100.htm#dxcfmsg">Modify automation that references output from D XCF,SYSPLEX
console commands</a></li>
<li><a href="e0z3m100.htm#dt2mg297">Update automation that handles messages IEE302I, IEE303I, IEE1302I,
IEE1303I, and IOS566I ****** POSSIBLY REMOVED AS AN ACTION****************</a></li>
<li><a href="e0z3m100.htm#resolver2">IP Services: Update automation to monitor resolver address
space initialization completion messages</a></li>
<li><a href="e0z3m100.htm#ipauto">IP Services: Update automation on D TCPIP,tnproc,&lt;Telnet&gt;,CONN
 for the expanded EN TY column in message EZZ6064I</a></li>
<li><a href="e0z3m100.htm#jes3msg">Update automation that handles message IAT3100</a></li>
<li><a href="e0z3m100.htm#msgerb81">Check your automation for Monitor III messages ERB812I and
ERB813I</a></li></ul>
<p><strong>Reference information</strong>: For a list of changed and deleted
messages, see <cite>z/OS Summary of Message and Interface Changes</cite>.</p>
<h4 id="at3geng">Rework and install user modifications</h4>
<p><strong>Description</strong>: A user modification is a change constructed
by a user to modify an existing function, add to an existing function,
or add a user-defined function. <a id="idx126"></a><a id="idx127"></a><a id="idx128"></a><a id="idx129"></a><a id="idx130"></a><a id="idx131"></a> Common types of
user modifications are:  
</p>
<ul>
<li>User-written and vendor-written exit routines.</li>
<li>User-written and vendor-written SVCs.</li>
<li>User-written and vendor-written termination routines.</li>
<li>Modifications of IBM source
code.</li>
<li>Unit information modules (UIMs) for non-IBM hardware.</li>
<li>User-written and vendor-written modules that are listed in a NUCLST<span class="synph"><span class="var">xx</span></span> parmlib
member.</li>
<li>Updates to default modules to set site defaults differently than
the IBM-supplied defaults, such as for the following element and features: 

<ul>
<li>XL C/C++</li>
<li>DFSORT.
Consider using ICEPRM<span class="synph"><span class="var">xx</span></span> parmlib members,
introduced in z/OS V1R10, to
eliminate the assembler language installation option modules.</li>
<li>HLASM.</li>
<li>ISPF (specifically, the ISPF configuration table).</li>
<li>Language Environment&reg;. Consider using the CEEROPT module, which can be
used to specify runtime options for CICS&reg;, IMS&trade; LRR, and other LRR users. Beginning
in z/OS V2R1, for other assembler language runtime option modules,
you must migrate to use the CEEPRMxx parmlib member. See <a href="./am3le21.html">Determine the impact of added and changed runtime options</a> for
more information about CEEPRM<span class="synph"><span class="var">xx</span></span>.</li>
<li>SDSF. See <a href="e0z3m100.htm#ax3assm1">Use dynamic statements for ISFPARMS to avoid reassembly</a> for further information.</li></ul></li></ul>
<p>If you made any user modifications, you have to determine which
ones need to be reworked and which ones just need to be reinstalled.</p>
<table id="wq37" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you made any user modifications.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Use the z/OS SMP/E
Planning and Migration Assistant to help determine which user modifications
need to be reworked and which just have to be reinstalled. The Top
or New Intermediate Product Migration Changes Report uses data found
on your system, combined with IBM-supplied information from the Software
Information Base, to show you the current levels of products available
as well as product migration and functional changes using a comparison
of FMIDs. You can use this report to determine the product migration
impacts by reviewing the &quot;changed&quot; FMIDs. This can help you assess
how many user modifications have to be reworked if you issued the
LIST SYSMOD USERMOD FORFMID (listing the &quot;changed&quot; FMIDs) command.
All other user modifications can be reinstalled without having to
be reworked. </p>
<div>
<div class="note-noindent" id="wq38">
<span class="notetitle">Note:</span> <span class="notebody">IBM recommends
using exit routines for any user modifications where possible, and
installing the exit routines with SMP/E. By using SMP/E, it is easier
to bring forward modifications to the z/OS release you are installing.</span></div></div>
<p><strong>Reference information</strong>: 
</p>
<ul>
<li>For information about SDSF customization, see <span id="at3geng__isfa500t">z/OS V2R1.0 SDSF Operation and Customization</span>.</li>
<li>For information about XL C/C++ customization, see <cite>z/OS XL C/C++ User's Guide</cite>.</li>
<li>For information about DFSORT customization, see <cite>z/OS DFSORT Installation and Customization</cite>.</li>
<li>For information about HLASM customization, see <cite>HLASM Installation and Customization Guide</cite>.</li>
<li>For information about ISPF customization, see <cite>z/OS V2R1.0 ISPF Planning and Customizing</cite>.</li>
<li>For information about Language Environment customization,
see .</li></ul>
<h4 id="at3genh">Reconnect non-IBM products</h4>
<p><strong>Description</strong>: If you use any independent software
vendor (ISV) products, you need to make them usable with the new system.<a id="idx132"></a></p>
<table id="wq39" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use any ISV products and need to
reconnect them after performing a ServerPac or SystemPac installation.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td>
<p><strong>Target system software requirements</strong>:</p></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Check with your ISVs to make
sure the product levels you are using support the new z/OS release, and then reconnect
your ISV products to the new release of z/OS following the instructions
provided by the ISVs. If any ISV products do not need to be installed
in the same libraries and zones as z/OS,
place them in their own sets of libraries and SMP/E zones. This means
that, unless you have to change ISV product code, such as installing
PTFs, or obtain a new level of the product, you will not need to reinstall
it after you install a new ServerPac or SystemPac.</p>
<p><strong>Reference information</strong>:

</p>
<ul>
<li>For a list of independent software vendors (ISVs) that support z/OS, as well as announcements,
testimonials, and other information, see <a href="http://www.ibm.com/systems/z/solutions/isv/">http://www.ibm.com/systems/z/solutions/isv/</a>. <a id="idx133"></a><a id="idx134"></a><a id="idx135"></a></li>
<li>For a directory of ISV products that support z/OS, see the Global Solutions Directory at <a href="http://www.ibm.com/software/solutions/isv">http://www.ibm.com/software/solutions/isv</a>.</li></ul>
<h4 id="at3geni">Reconnect subsystems</h4>
<p><strong>Description</strong>: If you use subsystems, you need to make them
usable with the new system.<a id="idx136"></a></p>
<table id="wq40" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you will use CICS, DB2&reg;, IMS, or NCP on your new system.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Ensure that any required target
system PTFs are installed before using the subsystem with the new z/OS system, as well as any required
SVCs, system modifications, parmlib setup, and proclib setup. Follow
the instructions for the subsystem that you need to reconnect.</p>
<p><strong>Tip</strong>: IBM PTFs that are required for z/OS V2R1 are
identified with the FIXCAT IBM.TargetSystem-RequiredService.z/OS.V2R1</p>
<p><strong>Reference information</strong>: 
</p>
<ul>
<li>Subsystem program directories</li>
<li>"Appendix B. Software requirements for running z/OS V2R1" in <cite>z/OS Planning
for Installation</cite></li></ul><p class="indatacontent">.</p>
<h4 id="at3genj">Update operational and other procedures</h4>
<p><strong>Description</strong>: Depending on which method you
used to install (ServerPac, CBPDO, or other deliverable), and which
functions you plan to exploit, you might need to update the operation,
automation, administration, security, backup, and recovery procedures
for your site. <a id="idx137"></a></p>
<table id="wq41" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Review your operation, automation,
administration, security, backup, and recovery procedures, and make
any necessary changes depending on how you installed and which functions
you plan to exploit. Some possible changes are: 

</p>
<ul>
<li>Allowing applicable users access to new high-level qualifiers.
The default new high-level qualifiers are shown in <a href="e0z3m100.htm#at3genf">Add references to new data sets and paths</a>.</li>
<li>Updating and testing your backup and recovery procedures to accommodate
the new target system.</li>
<li>Updating and testing any disaster recovery procedures.</li>
<li>Updating and testing any automation procedures to take advantage
of new functions.</li>
<li>Updating security system definitions, such as defining new users
and resources, permitting users to use new resources, and defining
new profiles in the RACF FACILITY
class.<a id="idx138"></a></li></ul>
<p><strong>Reference information</strong>: For the RACF FACILITY class profiles that
were added for z/OS UNIX, see <cite>z/OS UNIX System Services Planning</cite>.</p>
<h4 id="at3limi">Verify that virtual storage limits are set properly</h4>
<p>[[[[ Originator: Kathy Walsh/Gaithersburg/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: Virtual storage requirements usually grow from
release to release. You should review the virtual storage limits you
want to set. Generally, there are two areas of concern: common areas
(above and below the 16 MB line) and individual address spaces. An
increase in virtual storage for common areas reduces the virtual storage
size of all address spaces. An increase in virtual storage for individual
address spaces impacts only the individual address spaces.<a id="idx139"></a><a id="idx140"></a></p>
<table id="wq42" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>Use IBM Health
Checker for z/OS to help determine whether your virtual storage limits
are set properly. The check RSM_MEMLIMIT checks the current setting
for the MEMLIMIT parameter in SMFPRM<span class="synph"><span class="var">xx</span></span>,
which affects the amount of virtual storage above the 2 GB bar that
is available to jobs. This check verifies that a nonzero MEMLIMIT
value is in use.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Determine how much virtual storage use to
allow above the 2 GB bar. While there is no practical limit to the
number of virtual addresses an address space can request above the
bar, the system can limit the amount of virtual storage above the
bar that an address space is allowed to use. The amount of virtual
storage above the bar is determined as follows. The MEMLIMIT parameter
in parmlib member SMFPRMxx sets the default system-wide limit,
which defaults to 2 GB as of z/OS V1R10 (and zero before z/OS V1R10).
However, the system-wide default MEMLIMIT can be overridden by specifying
REGION=0M or MEMLIMIT on JOB or EXEC statements in JCL. To set a limit
on the use of virtual storage above the bar, use the SMF exit IEFUSI.
For more information, see  in <cite>z/OS MVS Programming: Extended Addressability
Guide</cite>.<a id="idx141"></a></p>
<p>If you want to control the use of virtual storage above the 2 GB
bar, do one or more of the following: 
</p>
<ul>
<li>The MEMLIMIT default is 2 GB. If this 2 GB default value is acceptable
to you, no change to SMFPRM<span class="synph"><span class="var">xx</span></span> is necessary.
(Before z/OS V1R10, the default
MEMLIMIT was zero, and you had to specify a nonzero MEMLIMIT in an
active SMFPRM<span class="synph"><span class="var">xx</span></span> member of parmlib to establish
a system default other than zero for available virtual storage above
2 GB.)</li>
<li>You can specify MEMLIMIT explicitly in JCL to override the system
default that was set (or allowed to default) in SMFPRM<span class="synph"><span class="var">xx</span></span>.</li>
<li>You can specify REGION=0M on the job statement in JCL to implicitly
set MEMLIMIT to NOLIMIT, which also overrides the system default (from
SMFPRM<span class="synph"><span class="var">xx</span></span>).</li>
<li>You can use IEFUSI both to establish a system default MEMLIMIT
for different classes of work (for example, job, TSO, STC) and limit
the amount of virtual storage that can be used above the bar, provided
that an explicit or implicit nonzero MEMLIMIT is in effect from JCL
or SMFPRM<span class="synph"><span class="var">xx</span></span>. As of z/OS V1R10, keyword
HONORIEFUSIREGION | NOHONORIEFUSIREGION is available in SCHED<span class="synph"><span class="var">xx</span></span> to
identify if the region and MEMLIMIT settings specified through or
otherwise affected by the IEFUSI exit are to take effect for a program.
If you are overriding the attribute of HASJES20 (JES2) in SCHEDxx
parmlib member, specify NOHONORIEFUSIREGION explicitly so the default
of HONORIEFUSIREGION is not used for this program.</li></ul>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li>Information about how to evaluate the real storage configuration
can be found in the Washington Systems Center white paper <em>z/OS
Performance: Managing Processor Storage in an all &quot;Real&quot; Environment </em> at <a href=" http://www.ibm.com/support/techdocs/">ftp://public.dhe.ibm.com/software/mktsupport/techdocs/allreal.pdf</a>.
(Search for &quot;WP100269&quot;.) <a id="idx142"></a><a id="idx143"></a><a id="idx144"></a></li>
<li>For more information about controlling region size and region
limits using the IEFUSI exit, see <cite>z/OS MVS Initialization and Tuning Guide</cite>.</li>
<li>For more information about the HONORIEFUSIREGION keyword, see <cite>z/OS MVS Initialization and Tuning Reference</cite>.</li></ul>
<h4 id="at3back">Back virtual storage with sufficient real and auxiliary storage</h4>
<p><strong>Description</strong>:  As you exploit additional virtual
storage by defining additional address spaces or by exploiting memory
objects, ensure that you have defined sufficient real and auxiliary
storage. <a id="idx145"></a><a id="idx146"></a></p>
<table id="wq43" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Using an RMF&trade; report, determine whether additional real or
auxiliary storage is needed by checking the following real storage
concentration indicators:

</p>
<ul>
<li>UIC and average available frames</li>
<li>Demand page rates</li>
<li>Percentage of auxiliary slots in use</li></ul>
<p><strong>Reference information</strong>: For more information
about memory objects, see <cite>z/OS MVS Programming: Extended Addressability
Guide</cite> and
Washington Systems Center flash 10165 at <a href=" http://www.ibm.com/support/techdocs/">http://www.ibm.com/support/techdocs</a>.
(Search for &quot;flash10165&quot;.)<a id="idx147"></a><a id="idx148"></a><a id="idx149"></a></p>
<h4 id="uplochk">Update your check customization for modified IBM Health Checker for z/OS checks</h4>
<p>[[[[ Contributor: Marna Walle/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: Changes that IBM makes
to the checks provided by IBM Health
Checker for z/OS can affect
any updates you might have made.<a id="idx150"></a></p>
<p>The checks that are new in z/OS V2R1 are: 
</p>
<ul>
<li>ICSFMIG_DEPRECATED_SERV_WARNINGS</li>
<li>ICSFMIG7731_ICSF_RETAINED_RSAKEY</li>
<li>ICSF_COPROCESSOR_STATE_NEGCHANGE</li>
<li>RACF_AIM_STAGE</li>
<li>RACF_UNIX_ID</li>
<li>SUP_SYSTEM_SYMBOL_TABLE_SIZE. See <a href="e0z3m100.htm#li2657d">Accommodate the SETLOAD IEASYM command to update system symbols
without initiating an IPL</a>.</li>
<li>SYSTRACE_MODE</li>
<li>SYSTRACE_BRANCH</li>
<li>OCE_XTIOT_CHECK</li>
<li>VLF_MAXVIRT</li>
<li>ZOSMIGV2R1_DEFAULT_UNIX_ID</li></ul>
<p id="uplochk__r21chks">The checks that were changed by IBM in z/OS V2R1 are: 
</p>
<ul>
<li>ASM_LOCAL_SLOT_USAGE</li>
<li>ASM_PLPA_COMMON_USAGE</li>
<li>ASM_PLPA_COMMON_SIZE</li>
<li>CATALOG_IMBED_REPLICATE</li>
<li>RACF_<span class="synph"><span class="kwd">classname</span></span>_ACTIVE</li>
<li>RACF_SENSITIVE_RESOURCES</li>
<li>ZOSMIGV1R11_CS_DNSBIND</li>
<li>VSM_CSA_LARGEST_FREE</li>
<li>SLIP_PER</li>
<li>XCF_CF_STR_SCM_UTILIZATION</li>
<li>XCF_CF_SCM_UTILIZATION</li>
<li>XCF_CF_STR_MAXSCM</li>
<li>XCF_CF_STR_MAXSPACE</li>
<li>XCF_CF_STR_SCMMAXSIZE</li></ul>
<p id="uplochk__r13chks">The following check was new in z/OS V1R13: 
</p>
<ul>
<li>ZOSMIGV1R13_RO_SYMLINKS</li></ul>
<p>The checks that were changed by IBM in
z/OS V1R13 are: 
</p>
<ul>
<li>SUP_HiperDispatch</li>
<li>XCF_SFM_CFSTRHANGTIME</li></ul>
<p id="uplochk__nor13chks">The checks that were deleted by IBM in z/OS V1R13
are: 
</p>
<ul>
<li>CSVTAM_VIT_DSPSIZE</li>
<li>CSVTAM_VIT_SIZE</li></ul>
<p id="uplochk__r12chks">The checks that were changed by IBM in z/OS V1R12 are: 
</p>
<ul>
<li>USS_PARMLIB</li></ul>
<table id="wq44" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to ensure that your checks
continue to work as you intend them to work.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>See <strong>Steps to take</strong>: below.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Look at the updated checks in <cite>IBM Health Checker for z/OS: User's Guide</cite>.</li>
<li>Review changes you made for those checks, in HZSPRM<span class="synph"><span class="var">xx</span></span> parmlib
members, for example.</li>
<li>Make any further updates for the checks to ensure that they continue
to work as intended.</li></ol>
<p><strong>Reference information</strong>: For complete information about updating
checks, see "Customizing and managing checks" in <cite>IBM Health Checker for z/OS: User's Guide</cite>.</p>
<h4 id="at3gene">Remove deleted data sets, paths, and references</h4>
<p><strong>Description</strong>: Data sets and paths are routinely removed from
z/OS for reasons such as consolidation of data sets and removal of
elements and features. You must determine whether these changes affect
your environment.<a id="idx151"></a><a id="idx152"></a><a id="idx153"></a><a id="idx154"></a></p>
<table id="at3gene__elementorfeaturemultiple.whenchange" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Using <a href="e0z3m100.htm#at3gene__ldtab2">Table 4</a> as
a guide, remove data sets and paths that do not exist in the current
release (z/OS V2R1). Also, remove references to them. You might find
references in the following places: 
 
</p>
<ul>
<li>Parmlib</li>
<li>Proclib</li>
<li>Logon procedures</li>
<li>Catalogs</li>
<li>Security definitions, including program control definitions</li>
<li>DFSMS ACS
routines</li>
<li><samp class="xph">/etc/profile</samp></li>
<li>SMP/E DDDEF entry</li>
<li>Backup and recovery procedures, as well as any references to them</li></ul>
<p>In the tables <a href="e0z3m100.htm#at3gene__ldtab1">Table 3</a> and <a href="e0z3m100.htm#at3gene__ldtab2">Table 4</a>, the data sets are identified as
distribution library (DLIB) data sets or target library data sets.</p>
<table id="at3gene__ldtab1" width="100%" summary="" border="1" frame="border" rules="all">
<caption><a href="e0z3m100.htm#FT_Table_3">Table 3. Data sets and paths <strong>deleted</strong> from z/OS V2R1 (in alphabetic order by DDDEF name)</a></caption>
<thead valign="bottom">
<tr>
<th id="wq46" width="14%" align="left" valign="bottom">DDDEF</th>
<th id="wq47" width="22%" align="left" valign="bottom">Data set name or path (high-level
qualifiers are defaults)</th>
<th id="wq48" width="9%" align="left">DLIB or target</th>
<th id="wq49" width="20%" align="left" valign="bottom">From element or feature</th>
<th id="wq50" width="11%" align="left" valign="bottom">When deleted</th>
<th id="wq51" width="20%" align="left" valign="bottom">Why deleted</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq46">AEPHGIF</td>
<td headers="wq47">EPH.AEPHGIF DLIB</td>
<td headers="wq48">DLIB</td>
<td headers="wq49">Library Server</td>
<td headers="wq50">z/OS V2R1</td>
<td headers="wq51">Not needed for z/OS V2R1</td>
</tr>
<tr>
<td headers="wq46">AFOMDATA</td>
<td headers="wq47">SYS1.AFOMDATA</td>
<td headers="wq48">DLIB</td>
<td headers="wq49">z/OS UNIX</td>
<td headers="wq50">z/OS V2R1</td>
<td headers="wq51">ICLI removed from z/OS</td>
</tr>
<tr>
<td headers="wq46">SFOMDATA</td>
<td headers="wq47">SYS1.SFOMDATA</td>
<td headers="wq48">Target</td>
<td headers="wq49">z/OS UNIX</td>
<td headers="wq50">z/OS V2R1</td>
<td headers="wq51">ICLI removed from z/OS</td>
</tr>
<tr>
<td headers="wq46">SFOMEHFS</td>
<td headers="wq47">/usr/lpp/icli/IBM</td>
<td headers="wq48">Target</td>
<td headers="wq49">z/OS UNIX</td>
<td headers="wq50">z/OS V2R1</td>
<td headers="wq51">ICLI removed from z/OS</td>
</tr>
<tr>
<td headers="wq46">SFOMESBN</td>
<td headers="wq47">/usr/lpp/icli/sbin/IBM</td>
<td headers="wq48">Target</td>
<td headers="wq49">z/OS UNIX</td>
<td headers="wq50">z/OS V2R1</td>
<td headers="wq51">ICLI removed from z/OS</td>
</tr>
</tbody>
</table>
<table id="at3gene__ldtab2" width="100%" summary="" border="1" frame="border" rules="all">
<caption><a href="e0z3m100.htm#FT_Table_4">Table 4. Data sets and paths <strong>deleted</strong> from z/OS V1R13 (in alphabetic order by DDDEF name)Data sets and paths <strong>deleted</strong> from z/OS V1R13 (in alphabetic order by DDDEF name)</a></caption>
<thead valign="bottom">
<tr>
<th id="wq52" width="14%" align="left" valign="bottom">DDDEF</th>
<th id="wq53" width="21%" align="left" valign="bottom">Data set name or path (high-level
qualifiers are defaults)</th>
<th id="wq54" width="9%" align="left">DLIB or target</th>
<th id="wq55" width="21%" align="left" valign="bottom">From element or feature</th>
<th id="wq56" width="12%" align="left" valign="bottom">When deleted</th>
<th id="wq57" width="21%" align="left" valign="bottom">Why deleted</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq52">ABPAHFS</td>
<td headers="wq53">BPA.ABPAHFS</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">z/OS UNIX System Services</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">z/OS UNIX System Services Connection Manager
removed from z/OS</td>
</tr>
<tr>
<td headers="wq52">ACMXDBRM</td>
<td headers="wq53">CMX.ACMXDBRM</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">z/OS UNIX System Services</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">z/OS UNIX System Services Connection Manager
removed from z/OS</td>
</tr>
<tr>
<td headers="wq52">ACMXHFS</td>
<td headers="wq53">CMX.ACMXHFS</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">z/OS UNIX System Services</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">z/OS UNIX System Services Connection Manager
removed from z/OS</td>
</tr>
<tr>
<td headers="wq52">AEUVACF</td>
<td headers="wq53">EUV.AEUVACF</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVDBRM</td>
<td headers="wq53">EUV.AEUVDBRM</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVEXEC</td>
<td headers="wq53">EUV.AEUVEXEC</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVEXP</td>
<td headers="wq53">EUV.AEUVEXP</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVHDR</td>
<td headers="wq53">EUV.AEUVHDR</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVHDRK</td>
<td headers="wq53">EUV.AEUVHDRK</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVHDCP</td>
<td headers="wq53">EUV.AEUVHDCP</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVHETC</td>
<td headers="wq53">EUV.AEUVHETC</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVHINC</td>
<td headers="wq53">EUV.AEUVHINC</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVHJPN</td>
<td headers="wq53">EUV.AEUVHJPN</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVHLBR</td>
<td headers="wq53">EUV.AEUVHLBR</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVHTCL</td>
<td headers="wq53">EUV.AEUVHTCL</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVHXMP</td>
<td headers="wq53">EUV.AEUVHXMP</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVIDL</td>
<td headers="wq53">EUV.AEUVIDL</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVLIB</td>
<td headers="wq53">EUV.AEUVLIB</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVLIBK</td>
<td headers="wq53">EUV.AEUVLIBK</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVLIBS</td>
<td headers="wq53">EUV.AEUVLIBS</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVLINK</td>
<td headers="wq53">EUV.AEUVLINK</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVMSG</td>
<td headers="wq53">EUV.AEUVMSG</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVMSGJ</td>
<td headers="wq53">EUV.AEUVMSGJ</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVPNL</td>
<td headers="wq53">EUV.AEUVPNL</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVPNLJ</td>
<td headers="wq53">EUV.AEUVPNLJ</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AEUVPRC</td>
<td headers="wq53">EUV.AEUVPRC</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">AIOELMOD</td>
<td headers="wq53">IOE.AIOELMOD</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DFS</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">No load modules are installed in these libraries
as of z/OS V1R13.</td>
</tr>
<tr>
<td headers="wq52">AIOEMSGE</td>
<td headers="wq53">IOE.AIOEMSGE</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DFS</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">English message library is no longer provided
as of z/OS V1R13.</td>
</tr>
<tr>
<td headers="wq52">AIOEMSGJ</td>
<td headers="wq53">IOE.AIOEMSGJ</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DFS</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">Japanese message library is no longer provided
in z/OS V1R13.</td>
</tr>
<tr>
<td headers="wq52">AIOEPNLE</td>
<td headers="wq53">IOE.AIOEPNLE</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DFS</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">English panel library is no longer provided
in z/OS V1R13.</td>
</tr>
<tr>
<td headers="wq52">AIOEPNLJ</td>
<td headers="wq53">IOE.AIOEPNLJ</td>
<td headers="wq54">DLIB</td>
<td headers="wq55">DFS</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">Japanese panel library is not provided in
z/OS V1R13.</td>
</tr>
<tr>
<td headers="wq52">SBPABIN</td>
<td headers="wq53">/usr/lpp/bpa/bin/IBM/</td>
<td headers="wq54">Target</td>
<td headers="wq55">z/OS UNIX System Services</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">z/OS UNIX System Services Connection Manager
removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SBPAINC</td>
<td headers="wq53">/usr/lpp/bpa/include/IBM/</td>
<td headers="wq54">Target</td>
<td headers="wq55">z/OS UNIX System Services</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">z/OS UNIX System Services Connection Manager
removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SBPALIB</td>
<td headers="wq53">/usr/lpp/bpa/lib/IBM/</td>
<td headers="wq54">Target</td>
<td headers="wq55">z/OS UNIX System Services</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">z/OS UNIX System Services Connection Manager
removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SBPAMSC</td>
<td headers="wq53">/usr/lpp/bpa/nls/msg/C/IBM/</td>
<td headers="wq54">Target</td>
<td headers="wq55">z/OS UNIX System Services</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">z/OS UNIX System Services Connection Manager
removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SBPAMJPN</td>
<td headers="wq53">/usr/lpp/bpa/nls/msg/Ja_JP/IBM/</td>
<td headers="wq54">Target</td>
<td headers="wq55">z/OS UNIX System Services</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">z/OS UNIX System Services Connection Manager
removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SBPASAMP</td>
<td headers="wq53">/usr/lpp/bpa/samples/IBM/</td>
<td headers="wq54">Target</td>
<td headers="wq55">z/OS UNIX System Services</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">z/OS UNIX System Services Connection Manager
removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SCEEUMAP</td>
<td headers="wq53">CEE.SCEEUMAP</td>
<td headers="wq54">Target</td>
<td headers="wq55">Language
Environment</td>
<td headers="wq56">z/OS V1R12</td>
<td headers="wq57">The SCEEUMAP data set will no longer be
shipped.</td>
</tr>
<tr>
<td headers="wq52">SCMXBIN</td>
<td headers="wq53">/usr/lpp/cmx/bin/IBM/</td>
<td headers="wq54">Target</td>
<td headers="wq55">z/OS UNIX System Services</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">z/OS UNIX System Services Connection Manager
removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SCMXDBRM</td>
<td headers="wq53">CMX.SCMXDBRM</td>
<td headers="wq54">Target</td>
<td headers="wq55">z/OS UNIX System Services</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">z/OS UNIX System Services Connection Manager
removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SCMXINC</td>
<td headers="wq53">/usr/lpp/cmx/include/IBM/</td>
<td headers="wq54">Target</td>
<td headers="wq55">z/OS UNIX System Services</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">z/OS UNIX System Services Connection Manager
removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SCMXLIB</td>
<td headers="wq53">/usr/lpp/cmx/lib/IBM/</td>
<td headers="wq54">Target</td>
<td headers="wq55">z/OS UNIX System Services</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">z/OS UNIX System Services Connection Manager
removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SCMXMJPN</td>
<td headers="wq53">/usr/lpp/cmx/nls/msg/Ja_JP/IBM/</td>
<td headers="wq54">Target</td>
<td headers="wq55">z/OS UNIX System Services</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">z/OS UNIX System Services Connection Manager
removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SCMXMSC</td>
<td headers="wq53">/usr/lpp/cmx/nls/msg/C/IBM/</td>
<td headers="wq54">Target</td>
<td headers="wq55">z/OS UNIX System Services</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">z/OS UNIX System Services Connection Manager
removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SCMXSAMP</td>
<td headers="wq53">/usr/lpp/cmx/samples/IBM/</td>
<td headers="wq54">Target</td>
<td headers="wq55">z/OS UNIX System Services</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">z/OS UNIX System Services Connection Manager
removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVACF</td>
<td headers="wq53">EUV.SEUVACF</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVDBRM</td>
<td headers="wq53">EUV.SEUVDBRM</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVEXEC</td>
<td headers="wq53">EUV.SEUVEXEC</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVEXP</td>
<td headers="wq53">EUV.SEUVEXP</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVHBIN</td>
<td headers="wq53">/usr/lpp/dce/bin/IBM/</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVHDCP</td>
<td headers="wq53">/usr/lpp/dce/dcecp/IBM/</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVHDR</td>
<td headers="wq53">EUV.SEUVHDR</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVHDRK</td>
<td headers="wq53">EUV.SEUVHDRK</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVHETC</td>
<td headers="wq53">/usr/lpp/dce/etc/IBM/</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVHINC</td>
<td headers="wq53">/usr/lpp/dce/share/include/IBM/</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVHJPN</td>
<td headers="wq53">/usr/lpp/dce/lib/nls/msg/Ja_JP/IBM/</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS..</td>
</tr>
<tr>
<td headers="wq52">SEUVHLBR</td>
<td headers="wq53">/usr/lpp/dce/lib/IBM/</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVHTCL</td>
<td headers="wq53">/usr/lpp/dce/tcl/IBM/</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVHXMP</td>
<td headers="wq53">/usr/lpp/dce/examples/IBM/</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVLIB</td>
<td headers="wq53">EUV.SEUVLIB</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVLIBK</td>
<td headers="wq53">EUV.SEUVLIBK</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVLIBS</td>
<td headers="wq53">EUV.SEUVLIBS</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVIDL</td>
<td headers="wq53">EUV.SEUVIDL</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVLINK</td>
<td headers="wq53">EUV.SEUVLINK</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVLPA</td>
<td headers="wq53">EUV.SEUVLPA</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVMSG</td>
<td headers="wq53">EUV.SEUVMSG</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVMSGJ</td>
<td headers="wq53">EUV.SEUVMSGJ</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVPNL</td>
<td headers="wq53">EUV.SEUVPNL</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVPNLJ</td>
<td headers="wq53">EUV.SEUVPNLJ</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SEUVPRC</td>
<td headers="wq53">EUV.SEUVPRC</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">DCE removed from z/OS.</td>
</tr>
<tr>
<td headers="wq52">SIOELMOD</td>
<td headers="wq53">IOE.SIOELMOD</td>
<td headers="wq54">Target</td>
<td headers="wq55">DFS</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">No load modules are installed in these libraries
as of z/OS V1R13.</td>
</tr>
<tr>
<td headers="wq52">SIOEMSGE</td>
<td headers="wq53">IOE.SIOEMSGE</td>
<td headers="wq54">Target</td>
<td headers="wq55">DFS</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">English message library is no longer provided
as of z/OS V1R13.</td>
</tr>
<tr>
<td headers="wq52">SIOEMSGJ</td>
<td headers="wq53">IOE.SIOEMSGJ</td>
<td headers="wq54">Target</td>
<td headers="wq55">DFS</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">Japanese message library is no longer provided
in z/OS V1R13.</td>
</tr>
<tr>
<td headers="wq52">SIOEPNLE</td>
<td headers="wq53">IOE.SIOEPNLE</td>
<td headers="wq54">Target</td>
<td headers="wq55">DFS</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">English panel library is no longer provided
in z/OS V1R13.</td>
</tr>
<tr>
<td headers="wq52">SIOEPNLJ</td>
<td headers="wq53">IOE.SIOEPNLJ</td>
<td headers="wq54">Target</td>
<td headers="wq55">DFS</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57">Japanese panel library is not provided in
z/OS V1R13.</td>
</tr>
<tr>
<td headers="wq52">None. See comments in <strong>Why deleted</strong>.</td>
<td headers="wq53">/etc/dce</td>
<td headers="wq54">Target</td>
<td headers="wq55">DCE</td>
<td headers="wq56">z/OS V1R13</td>
<td headers="wq57"> These entries do not have DDDEFs associated
with the directories; all files and directories can be removed. Note
that if <strong>/krb5</strong> is a symbolic link to the<strong> /etc/dce</strong> directory,
deleting <strong>/etc/dce</strong> removes it as well. Ensure that when you
delete <strong>/etc/dce</strong> you are not removing anything for <strong>/krb5</strong> that
is defined for Kerberos.</td>
</tr>
</tbody>
</table>
<div>
<div class="note-noindent" id="wq58">
<span class="notetitle">Note:</span> <span class="notebody">
<ol type="1">
<li>Ensure that references to the DCE target library EUV.SEUVLINK
and DFS target library IOE.SIOELMOD have been removed from your LNKLST
concatenation.  Ensure that any reference to DCE target library EUV.SEUVLPA
has been removed from the LPALST concatenation.</li>
<li>Do not remove any data sets, paths, or references that are needed
by earlier-level systems until those systems no longer need them.</li></ol></span></div></div>
<p><strong>Reference information</strong>: None.</p>
<h4 id="at3genf">Add references to new data sets and paths</h4>
<p><strong>Description</strong>: New data sets and paths are routinely added
to z/OS for reasons such as consolidation of data sets and addition
of new elements and features. You must determine whether these additions
affect your environment.<a id="idx155"></a><a id="idx156"></a></p>
<table id="wq60" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Using <a href="e0z3m100.htm#at3genf__dsadded">Table 5</a> as
a guide, add references in the following places for data sets and
paths that have been added to z/OS:  
</p>
<ul>
<li>Parmlib</li>
<li>Proclib</li>
<li>Logon procedures</li>
<li>Catalogs</li>
<li>Security definitions, including program control definitions</li>
<li>DFSMS ACS
routines</li>
<li>Any backup and recovery procedures.</li></ul>
<p><strong>Rules</strong>: Some of the data sets shipped with z/OS are PDSEs and are most likely in your link
list. If one or more are in your link list and on your system residence
volume, adhere to the following PDSE sharing rules to avoid data set
corruption:<a id="idx157"></a><a id="idx158"></a>  
</p>
<ul>
<li>If you specified PDSESHARING(NORMAL), do not share PDSE data sets
beyond the scope of the global resource serialization complex.</li>
<li>If you specified PDSESHARING(EXTENDED), do not share PDSE data
sets beyond the scope of the sysplex.</li></ul>
<table id="at3genf__dsadded" width="100%" summary="" border="1" frame="border" rules="all">
<caption><a href="e0z3m100.htm#FT_Table_5">Table 5. Data sets <strong>added</strong> to z/OS V2R1 and z/OS V1R13 (in alphabetic order by DDDEF name)</a></caption>
<thead valign="bottom">
<tr>
<th id="wq61" width="10%" align="left" valign="bottom">DDDEF</th>
<th id="wq62" width="19%" align="left" valign="bottom">Data set name (high-level qualifiers
are defaults) or path</th>
<th id="wq63" width="10%" align="left">DLIB or target</th>
<th id="wq64" width="24%" align="left" valign="bottom">To element or feature</th>
<th id="wq65" width="10%" align="left" valign="bottom">When added</th>
<th id="wq66" width="25%" align="left" valign="bottom">Why added</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq61">AEPHPLIB</td>
<td headers="wq62">EPH.AEPHPLIB</td>
<td headers="wq63">DLIB</td>
<td headers="wq64">Library Server</td>
<td headers="wq65">z/OS V2R1</td>
<td headers="wq66">New data set for Library Server</td>
</tr>
<tr>
<td headers="wq61">AEPHTAB</td>
<td headers="wq62">AEPHTAB EPH.AEPHTAB</td>
<td headers="wq63">DLIB</td>
<td headers="wq64">Library Server</td>
<td headers="wq65">z/OS V2R1</td>
<td headers="wq66">New data set for Library Server</td>
</tr>
<tr>
<td headers="wq61">AFNT300</td>
<td headers="wq62">SYS1.AFNT300</td>
<td headers="wq63">DLIB</td>
<td headers="wq64">z/OS Font Collection</td>
<td headers="wq65">z/OS V2R1</td>
<td headers="wq66">Previously existing non-z/OS data set now
ships with the z/OS product as of z/OS V2R1</td>
</tr>
<tr>
<td headers="wq61">AFNTDLIB</td>
<td headers="wq62">SYS1.AFNTDLIB</td>
<td headers="wq63">DLIB</td>
<td headers="wq64">z/OS Font Collection</td>
<td headers="wq65">z/OS V2R1</td>
<td headers="wq66">New data set as of z/OS V2R1</td>
</tr>
<tr>
<td headers="wq61">AFNTILIB</td>
<td headers="wq62">SYS1.AFNTILIB</td>
<td headers="wq63">DLIB</td>
<td headers="wq64">z/OS Font Collection</td>
<td headers="wq65">z/OS V2R1</td>
<td headers="wq66">New data set as of z/OS V2R1</td>
</tr>
<tr>
<td headers="wq61">AFNTLIBB</td>
<td headers="wq62">SYS1.AFNTLIBB</td>
<td headers="wq63">DLIB</td>
<td headers="wq64">z/OS Font Collection</td>
<td headers="wq65">z/OS V2R1</td>
<td headers="wq66">Previously existing non-z/OS data set now
ships with the z/OS product as of z/OS V2R1</td>
</tr>
<tr>
<td headers="wq61">AFONTHFS</td>
<td headers="wq62">SYS1.AFONTHFS</td>
<td headers="wq63">DLIB</td>
<td headers="wq64">z/OS Font Collection</td>
<td headers="wq65">z/OS V2R1</td>
<td headers="wq66">New data set as of z/OS V2R1</td>
</tr>
<tr>
<td headers="wq61">FONT300</td>
<td headers="wq62">SYS1.FONT300</td>
<td headers="wq63">Target</td>
<td headers="wq64">z/OS Font Collection</td>
<td headers="wq65">z/OS V2R1</td>
<td headers="wq66">Previously existing non-z/OS data set now
ships with the z/OS product as of z/OS V2R1</td>
</tr>
<tr>
<td headers="wq61">FONTLIBB</td>
<td headers="wq62">SYS1.FONTLIBB</td>
<td headers="wq63">Target</td>
<td headers="wq64">z/OS Font Collection</td>
<td headers="wq65">z/OS V2R1</td>
<td headers="wq66">Previously existing non-z/OS data set now
ships with the z/OS product as of z/OS V2R1</td>
</tr>
<tr>
<td headers="wq61">SEPHPLIB</td>
<td headers="wq62">/usr/lpp/booksrv/plugins/IBM/</td>
<td headers="wq63">Target</td>
<td headers="wq64">Library Server</td>
<td headers="wq65">z/OS V2R1</td>
<td headers="wq66">New path for Library Server</td>
</tr>
<tr>
<td headers="wq61">SERBHFS</td>
<td headers="wq62">/usr/lpp/gpm/IBM</td>
<td headers="wq63">Target</td>
<td headers="wq64">RMF</td>
<td headers="wq65">z/OS V1R13</td>
<td headers="wq66">New RMF file system path for RMF XP.</td>
</tr>
<tr>
<td headers="wq61">SFNTILIB</td>
<td headers="wq62">SYS1.SFNTLIB</td>
<td headers="wq63">Target</td>
<td headers="wq64">z/OS Font Collection</td>
<td headers="wq65">z/OS V2R1</td>
<td headers="wq66">New data set as of z/OS V2R1</td>
</tr>
<tr>
<td headers="wq61">SFNTWTYP</td>
<td headers="wq62">/usr/lpp/fonts/worldtype/IBM/</td>
<td headers="wq63">Target</td>
<td headers="wq64">z/OS Font Collection</td>
<td headers="wq65">z/OS V2R1</td>
<td headers="wq66">New path as of z/OS V2R1</td>
</tr>
<tr>
<td headers="wq61">SFONDLIB</td>
<td headers="wq62">SYS1.SFONDLIB</td>
<td headers="wq63">Target</td>
<td headers="wq64">z/OS Font Collection</td>
<td headers="wq65">z/OS V2R1</td>
<td headers="wq66">New data set as of z/OS V2R1</td>
</tr>
</tbody>
</table>
<p><strong>Reference information</strong>: None.</p>
<h4 id="maxusers">Accommodate new address spaces</h4><a id="idx159"></a>
<p></p>
<p><strong>Description</strong>: The MAXUSER value in parmlib member IEASYSxx
specifies a value that the system uses to limit the number of jobs
and started tasks that can run concurrently during a given IPL. You
might want to increase your MAXUSER value to take new address spaces
into account.</p>
<p>The following address spaces are new for z/OS V2R1:
</p>
<ul>
<li>IBM Health Checker for z/OS.</li>
<li>JES2 NJE over TCP/IP: As of z/OS V1R7 JES2, NJE over TCP/IP runs
in a new address space. The address space is responsible for sending
data to, and receiving data from, TCP/IP. This move of processing
from the JES2 main task to the user environment is designed to improve
reliability, availability, and serviceability by isolating the moved
function from processing in the JES2 main task, and to improve performance
by taking advantage of multiple CPUs to do the work (so that not all
work is done under the single JES2 main task).| One address space
is created for each active JES2 NETSERV. The format of the name of
the address space is <samp class="xph">jjjjSnnn</samp>, where <samp class="xph">jjjj</samp> is
the owning JES2 subsystem name and nnn is the subscript of the owning
NETSERV. For example, for NETSERV(1) owned by subsystem JES2, the
name would be <samp class="xph">JES2S001</samp>.</li></ul>
<p>There are two new address spaces in z/OS V1R13. 
</p>
<ul>
<li>GPM4CIM is an address space to be used for cross-platform performance
management with RMF XP. You can start it by using procedure SYS1.PROCLIB(GPM4CIM)
from the console, as started task, with the following command: 
<pre class="xmp"><code>s gpm4cim[.identifier],os=A|X|Z</code></pre>Since
you can run multiple GPM4CIM instances simultaneously, it is recommended
to assign an identifier that you can use for subsequent STOP or MODIFY
commands. You may already have created the userID GPMSERVE as owner
of the GPMSERVE procedure. The GPM4CIM started task can be assigned
to the same userID with the following command:  
<pre class="xmp"><code>RDEFINE STARTED GPM4CIM.* STDATA(USER(GPMSERVE) TRUSTED(YES))</code></pre>For
more information, see <cite>z/OS RMF User's Guide</cite></li>
<li>As of z/OS V1R13 the Runtime Diagnostics address space HZR will
be a persistent address space. When the HZR address space is started
with the START command S HZR,SUB=MSTR, it will remain active until
stopped with the STOP command P HZR. To analyze a system, enter the
MODIFY HZR,ANALYZE command. See <a href="e0z3m100.htm#commndxx">Start Runtime Diagnostics at system initialization</a>.</li></ul>
<table id="wq67" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>
<ul>
<li>BCP for HZR</li>
<li>RMF for GPM4CIM.</li></ul></td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>
<ul>
<li>z/OS V1R13 for GPM4CIM and HZR</li>
<li>z/OS V2R1 change for IBM Health Checker for z/OS.</li></ul></td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to ensure that your MAXUSER
value in parmlib member IEASYSxx is adequate.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If necessary, increase your MAXUSER value
in parmlib member IEASYSxx to take the new address spaces into account.
One way to find out how many address spaces you use is to issue the
DISPLAY A,L command and total the address spaces in the IEE114I and
IEE115I messages on the old and new systems.</p>
<p></p>
<div>
<div class="note-noindent" id="wq68">
<span class="notetitle">Note:</span> <span class="notebody">
<ul>
<li>A modest overspecification of MAXUSER should not affect system
performance.</li>
<li>The number of total address spaces is the sum of M/S, TS USERS,
SYSAS, and INITS.</li>
<li>If you change your MAXUSER value, you must re-IPL to make the
change effective.</li></ul></span></div></div>
<p><strong>Reference information:</strong>  For more information about the MAXUSER
parameter, including its interaction with the RSVSTRT and RSVNONR
parameters and factors that contribute to the number of active address
spaces, see "Statements and parameters for IEASYSxx" in <cite>z/OS MVS Initialization and Tuning Reference</cite>.</p>
<h3 id="e0z3m100-gen8">Migration actions for everyone after the first IPL of z/OS V2R1</h3>
<p>This topic describes migration actions that you can perform only
after you have IPLed z/OS V2R1. You need a running z/OS V2R1 system
to perform these actions.</p>
<p>None.</p>
<h2 id="au1hard2">Hardware migration actions</h2>
<p>This topic describes hardware migration actions. The information
in this topic is not specifically related to migrating to z/OS V1R13; it only applies if
you are changing hardware. Therefore, this topic does not categorize
the actions in terms of when they should be performed (before installing,
before the first IPL, or after the first IPL).</p>
<h3 id="znext21">Migrate to an IBM zEnterprise EC12 server or IBM zEnterprise
BC12 server</h3><a id="idx160"></a><a id="idx161"></a><a id="idx162"></a><a id="idx163"></a><a id="idx164"></a><a id="idx165"></a><a id="idx166"></a><a id="idx167"></a><a id="idx168"></a><a id="idx169"></a><a id="idx170"></a><a id="idx171"></a><a id="idx172"></a><a id="idx173"></a><a id="idx174"></a><a id="idx175"></a><a id="idx176"></a><a id="idx177"></a>
<p>[[[[ Technical contacts: Gregory Daynes/Poughkeepsie/IBM@IBMUS,
Marna Walle/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: An IBM zEnterprise EC12 (zEC1) and
IBM zEnterprise Next BC12 (zBC12) server can include the following
in a zEnterprise environment: 
</p>
<ul>
<li>IBM zEnterprise EC12 server Central Processing Complex (CPC) or
IBM zEnterprise BC12 server CPC</li>
<li>zEnterprise BladeCenter Extension (zBX) Model 003 with its integrated
optimizers or select IBM blades</li>
<li>zEnterprise Unified Resource Manager (Unified Resource Manager)</li></ul>
<p> The zEC12 and zBC12 are the newest IBM System z servers
and distinct from the earlier zEnterprise and other servers. In this
publication the IBM zEnterprise EC12  server is referred to as the
model zEC12 server and the IBM zEnterprise BC12  server is referred
to as the model zBC12 server.</p>
<p> In a Parallel Sysplex you can include the following servers:
</p>
<ul>
<li>zEC12 and zBC12 servers</li>
<li>zEnterprise servers (z196 or z114)</li>
<li>z10 EC and z10 BC servers.</li></ul>
<p>The specific zEC12 and zBC12 functions including base
support that are exploited by z/OS depend on the z/OS release. Availability
and other restrictions are noted in the <strong>Notes</strong> column. PTFs
might be required for many of these functions.  See <a href="e0z3m100.htm#znextbef21">Actions you can take before you order a zEC12 or zBC12 server</a> for information about finding
the appropriate PTFs.</p>
<table id="znext21__znextfuncbc" width="100%" summary="" border="1" frame="border" rules="all">
<caption><a href="e0z3m100.htm#FT_Table_6">Table 6. zEC12 and zBC12 server functions included in the base support for z/OS V1R12, z/OS V1R13, and z/OS V2R1</a></caption>
<thead valign="bottom">
<tr>
<th id="wq69" width="37%" align="left"><strong>zEC12 and zBC12 function included
in base z/OS support</strong>:

<ul>
<li>Y=Yes</li>
<li>N=No</li></ul></th>
<th id="wq70" width="20%" align="left">R12<sup>1</sup></th>
<th id="wq71" width="20%" align="left">R13<sup>1</sup></th>
<th id="wq72" width="20%" align="left">V2R1<sup>1</sup></th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left" headers="wq69">Base support</td>
<td align="left" headers="wq70">Y</td>
<td align="left" headers="wq71">Y</td>
<td align="left" headers="wq72">Y</td>
</tr>
<tr>
<td align="left" headers="wq69">OSA-Express4S (GbE LX and SX, 1000BASE-T,
10 GbE LR and SR)</td>
<td align="left" headers="wq70">Y</td>
<td align="left" headers="wq71">Y</td>
<td align="left" headers="wq72">Y</td>
</tr>
<tr>
<td align="left" headers="wq69">OSA-Express5S (GbE LX and SX, 1000BASE-T,
10 GbE LR and SR)</td>
<td align="left" headers="wq70">Y</td>
<td align="left" headers="wq71">Y</td>
<td align="left" headers="wq72">Y</td>
</tr>
<tr>
<td align="left" headers="wq69">FICON Express 8S (CHPID FC)</td>
<td align="left" headers="wq70">Y</td>
<td align="left" headers="wq71">Y</td>
<td align="left" headers="wq72">Y</td>
</tr>
<tr>
<td align="left" headers="wq69">High Performance FICON (zHPF)</td>
<td align="left" headers="wq70">Y</td>
<td align="left" headers="wq71">Y</td>
<td align="left" headers="wq72">Y</td>
</tr>
<tr>
<td align="left" headers="wq69">Parallel Sysplex InfiniBand (PSIFB)
Coupling Link</td>
<td align="left" headers="wq70">Y</td>
<td align="left" headers="wq71">Y</td>
<td align="left" headers="wq72">Y</td>
</tr>
<tr>
<td align="left" headers="wq69">CPU measurement facility</td>
<td align="left" headers="wq70">Y</td>
<td align="left" headers="wq71">Y</td>
<td align="left" headers="wq72">Y</td>
</tr>
<tr>
<td align="left" headers="wq69">New z/Architecture assembler instructions</td>
<td align="left" headers="wq70">Y</td>
<td align="left" headers="wq71">Y</td>
<td align="left" headers="wq72">Y</td>
</tr>
<tr>
<td align="left" headers="wq69">Crypto Express3 Toleration (if
carried forward)</td>
<td align="left" headers="wq70">Y</td>
<td align="left" headers="wq71">Y</td>
<td align="left" headers="wq72">Y</td>
</tr>
<tr>
<td align="left" headers="wq69">IBM zEnterprise United Resource
Manager</td>
<td align="left" headers="wq70">Y</td>
<td align="left" headers="wq71">Y</td>
<td align="left" headers="wq72">Y</td>
</tr>
<tr>
<td align="left" headers="wq69">IBM zEnterprise BladeCenter Extension
(zBX) Model 3</td>
<td align="left" headers="wq70">Y</td>
<td align="left" headers="wq71">Y</td>
<td align="left" headers="wq72">Y</td>
</tr>
<tr>
<td align="left" headers="wq69">GRS FICON CTC toleration</td>
<td align="left" headers="wq70">Y (requires additional PTFs for
exploitation)<sup>2</sup></td>
<td align="left" headers="wq71">Y (requires additional PTFs for
exploitation)<sup>2</sup></td>
<td align="left" headers="wq72">Y</td>
</tr>
</tbody>
</table>
<p></p>
<div>
<div class="note-noindent" id="wq73">
<span class="notetitle">Note:</span> <span class="notebody">
<ol type="1">
<li>PTFs for base support have a fix category of either: 

<ul>
<li>For EC12: IBM.Device.Server.zEC12-2827</li>
<li>For BC12: IBM.Device.Server.zBC12-2828</li></ul></li>
<li>PTFs for exploitation have a fix category of either:

<ul>
<li>For zEC12: IBM.Device.Server.zEC12-2827.Exploitation</li>
<li>For zBC12: IBM.Device.Server.zEC12-2828.Exploitation</li></ul></li>
<li>PTFs for zEDC exploitation or software decompression have a fix
category of either: 

<ul>
<li>For EC12: IBM.Device.Server.zEC12-2827.zEnterpriseDataCompression</li>
<li>For BC12: IBM.Device.Server.zBC12-2828.zEnterpriseDataCompression</li></ul></li></ol></span></div></div>
<table id="znext21__znextbcexp1" width="100%" summary="" border="1" frame="border" rules="all">
<caption><a href="e0z3m100.htm#FT_Table_7">Table 7. Exploitation of zEC12 and zBC12 server functions supported by z/OS V1R12, z/OS V1R13, and z/OS V2R1</a></caption>
<thead valign="bottom">
<tr>
<th id="wq75" width="33%" align="left"><strong>zBC12 functional exploitation
of z/OS support</strong>:

<ul>
<li>Y=Yes</li>
<li>N=No</li></ul></th>
<th id="wq76" width="21%" align="left">R12<sup>2</sup></th>
<th id="wq77" width="22%" align="left">R13<sup>2</sup></th>
<th id="wq78" width="22%" align="left">V2R1<sup>2</sup></th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left" headers="wq75">Coupling Facility Control Code
(CFCC) Level 18</td>
<td align="left" headers="wq76">Y</td>
<td align="left" headers="wq77">Y</td>
<td align="left" headers="wq78">Y</td>
</tr>
<tr>
<td align="left" headers="wq75">Coupling Facility Control Code
(CFCC) Level 19</td>
<td align="left" headers="wq76">Y</td>
<td align="left" headers="wq77">Y</td>
<td align="left" headers="wq78">Y</td>
</tr>
<tr>
<td align="left" headers="wq75">Coupling Facility Control Code
(CFCC) Level 19 Coupling thin interrupt support</td>
<td align="left" headers="wq76">Y</td>
<td align="left" headers="wq77">Y</td>
<td align="left" headers="wq78">Y</td>
</tr>
<tr>
<td align="left" headers="wq75">Crypto Express4S CCA enhancements
including: DK AES PIN, Export TDES key under AES transport key, Diversified
Key Generation CBC, IPEK, RKX key wrapping method, and  Integration
of UDX into CCA</td>
<td align="left" headers="wq76">N</td>
<td align="left" headers="wq77">Y (requires Cryptographic Support
for z/OS V1R13-z/OS V2R1 web deliverable)</td>
<td align="left" headers="wq78">Y (requires Cryptographic Support
for z/OS V1R13-z/OS V2R1 web deliverable)</td>
</tr>
<tr>
<td align="left" headers="wq75">Crypto Express4S: EP11 enhancements
when the Crypto Express4S PCIe adapter is configured as an EP11 coprocessor
including: (PKCS #11 v2.1 PSS, EP11 Key agreement algorithms, and
Offload Generation of Domain Parameters)</td>
<td align="left" headers="wq76">N</td>
<td align="left" headers="wq77">Y (requires Cryptographic Support
for z/OS V1R12-z/OS V1R13 web deliverable)</td>
<td align="left" headers="wq78">Y</td>
</tr>
<tr>
<td align="left" headers="wq75">Flash  Express (Storage Class Memory
or SCM)</td>
<td align="left" headers="wq76">N</td>
<td align="left" headers="wq77">Y (requires the z/OS V1R13 RSM
Enablement Offering Web deliverable)</td>
<td align="left" headers="wq78">Y</td>
</tr>
<tr>
<td align="left" headers="wq75">Pageable 1 MB Large Page Support.</td>
<td align="left" headers="wq76">N</td>
<td align="left" headers="wq77">Y (requires the z/OS V1R13 RSM
Enablement Offering Web deliverable)</td>
<td align="left" headers="wq78">Y</td>
</tr>
<tr>
<td align="left" headers="wq75">Dynamic reconfiguration support
for Flash Express.</td>
<td align="left" headers="wq76">N</td>
<td align="left" headers="wq77">Y (requires the z/OS V1R13 RSM
Enablement Offering Web deliverable)</td>
<td align="left" headers="wq78">Y</td>
</tr>
<tr>
<td align="left" headers="wq75">2 GB Large Page support.</td>
<td align="left" headers="wq76">N</td>
<td align="left" headers="wq77">Y (requires the z/OS V1R13 RSM
Enablement Offering Web deliverable) )</td>
<td align="left" headers="wq78">Y</td>
</tr>
<tr>
<td align="left" headers="wq75">Optional PLPA/common page data
set support.</td>
<td align="left" headers="wq76">N</td>
<td align="left" headers="wq77">Y (requires the z/OS V1R13 RSM
Enablement Offering Web deliverable and additional PTFs)</td>
<td align="left" headers="wq78">Y</td>
</tr>
<tr>
<td align="left" headers="wq75">10GbE RoCE Express</td>
<td align="left" headers="wq76">N</td>
<td align="left" headers="wq77">N</td>
<td align="left" headers="wq78">Y</td>
</tr>
<tr>
<td align="left" headers="wq75">Java Exploitation of Transactional
Execution (requires Java7 SR3)</td>
<td align="left" headers="wq76">N</td>
<td align="left" headers="wq77">Y (intended for testing environments)</td>
<td align="left" headers="wq78">Y</td>
</tr>
<tr>
<td align="left" headers="wq75">Java Exploitation of Runtime Instrumentation
(requires Java8)</td>
<td align="left" headers="wq76">N</td>
<td align="left" headers="wq77">N</td>
<td align="left" headers="wq78">Y</td>
</tr>
<tr>
<td align="left" headers="wq75"> IBM System Advanced Workload Analysis
Reporter (IBM zAware)</td>
<td align="left" headers="wq76">N</td>
<td align="left" headers="wq77">Y (requires additional PTFs for
exploitation)</td>
<td align="left" headers="wq78">Y</td>
</tr>
<tr>
<td align="left" headers="wq75">New z/Architecture instructions:
XL C/C++ ARCH(10) and TUNE(10) parameters</td>
<td align="left" headers="wq76">N</td>
<td align="left" headers="wq77">Y</td>
<td align="left" headers="wq78">Y</td>
</tr>
<tr>
<td align="left" headers="wq75">New z/Architecture Assembler Language
instruction mnemonic</td>
<td align="left" headers="wq76">N</td>
<td align="left" headers="wq77">N?</td>
<td align="left" headers="wq78">Y</td>
</tr>
<tr>
<td align="left" headers="wq75">zEDC capability using zEDC Express</td>
<td align="left" headers="wq76">N<sup>3</sup> (toleration support provided
for software decompression)</td>
<td align="left" headers="wq77">N<sup>3</sup> (toleration support provided
for software decompression)</td>
<td align="left" headers="wq78">Y<sup>3</sup> (requires the z/OS zEDC software
feature to be enabled)</td>
</tr>
<tr>
<td align="left" headers="wq75">LPAR enhancements for WLM/IRD</td>
<td align="left" headers="wq76">Y</td>
<td align="left" headers="wq77">Y</td>
<td align="left" headers="wq78">Y</td>
</tr>
<tr>
<td align="left" headers="wq75">LPAR enhancements for user group
capacity limit</td>
<td align="left" headers="wq76">Y</td>
<td align="left" headers="wq77">Y</td>
<td align="left" headers="wq78">Y</td>
</tr>
<tr>
<td align="left" headers="wq75">Add absolute physical hardware
LPAR capacity setting</td>
<td align="left" headers="wq76">Y</td>
<td align="left" headers="wq77">Y</td>
<td align="left" headers="wq78">Y</td>
</tr>
</tbody>
</table>
<div>
<div class="note-noindent" id="wq79">
<span class="notetitle">Note:</span> <span class="notebody">
<ol type="1">
<li>PTFs for base support have a fix category of either: 

<ul>
<li>For EC12: IBM.Device.Server.zEC12-2827</li>
<li>For BC12: IBM.Device.Server.zBC12-2828</li></ul></li>
<li>PTFs for exploitation have a fix category of either:

<ul>
<li>For zEC12: IBM.Device.Server.zEC12-2827.Exploitation</li>
<li>For zBC12: IBM.Device.Server.zEC12-2828.Exploitation</li></ul></li>
<li>PTFs for zEDC exploitation or software decompression have a fix
category of either: 

<ul>
<li>For EC12: IBM.Device.Server.zEC12-2827.zEnterpriseDataCompression</li>
<li>For BC12: IBM.Device.Server.zBC12-2828.zEnterpriseDataCompression</li></ul></li></ol></span></div></div>
<table id="wq81" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>
<ul>
<li>IBM zEnterprise EC12, which first shipped September 2012.</li>
<li>IBM zEnterprise BC12 (zBC12), which first shipped September
2013.</li></ul></td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Anytime before you introduce a zEC12 or zBC12
server into your environment.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to run z/OS V1R13 and V1R12
on a zEC12 or zBC12 server, or if you want to run a Coupling Facility
on a zEC12 or zBC12 server.  If you will run only a Coupling Facility
on a zEC12 or zBC12 system, then only the sysplex-related actions
below are relevant.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>
<ul>
<li>A zEC12 or zBC12</li>
<li>Additional hardware required for specific functions.

<ul>
<li>IBM devices previously attached to IBM System z10, z196 and zSeries
servers are supported for attachment to zEC12 channels, unless otherwise
noted. The subject I/O devices must meet FICON architecture requirements</li>
<li>IBM zAware requires the IBM zAware server firmware (FC #0011,
#0101, and #0102)</li>
<li>Flash Express requires FC #0402</li>
<li>zEDC Express requires FC #0420</li>
<li>10 GbE RoCE Express FC #0411</li>
<li>Use of IBMWebSphere DataPower Integration Appliance XI50 for zEnterprise
(DataPower XI50z) or select IBM BladeCenter PS701 Express blades or
IBM BladeCenter HX5 blades requires a zEnterprise BladeCenter Extension
(zBX) Model 003</li></ul></li></ul></td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>
<ol type="1">
<li>See the list of PTFs in the Software Service Level section of
the PSP buckets and use the SMP/E Fix Categories: 

<ul>
<li>For EC12 base support: IBM.Device.Server.zEC12-2827</li>
<li>For BC12 base support: IBM.Device.Server.zBC12-2828</li>
<li>For EC12 exploitation: IBM.Device.Server.zEC12-2827.Exploitation</li>
<li>For BC12 exploitation: IBM.Device.Server.zBC12-2828.Exploitation</li>
<li>For EC12 zEDC exploitation or toleration: IBM.Device.Server.zEC12-2827.zEnterpriseDataCompression</li>
<li>For BC12 zEDC exploitation or toleration: IBM.Device.Server.zBC12-2828.zEnterpriseDataCompression</li></ul></li>
<li>See <strong>Support is delivered by service and web deliverables</strong> described
in <a href="e0z3m100.htm#znextrec21">General recommendations and considerations for a zEC12 and
zBC12 server</a> and<strong> Install
the necessary z/OS service</strong>, as indicated in PSP buckets described
in <a href="e0z3m100.htm#znextbef21">Actions you can take before you order a zEC12 or zBC12 server</a></li></ol></td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>
<ul>
<li>It is recommended that you install and run the zEnterprise required
service on your existing server. This will enable you to fall back
from a hardware perspective, yet maintain your software level.</li>
<li>If you haven't installed the preconditioning and exploitation
PTFs for CFCC Level 17, Note that those PTFs are required to be installed
throughout your sysplex before implementing CFCC Level 18 or 19.</li>
<li>If you plan to implement zEDC, you should install the
z/OS toleration PTFs on systems that will access data that has been
compressed using zEDC Express on a zEC12 or zBC12 server.</li></ul></td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>See <a href="e0z3m100.htm#znextres21">Restrictions for a zEC12 or zBC12 server</a>.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>IBM Health Checker for z/OS check, SUP_HiperDispatchCPUConfig,
is added to z/OS V1R12 with APAR OA30476. This check will verify that
HiperDispatch is enabled on a zEC12 or zBC12 system.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Follow the <a href="e0z3m100.htm#znextrec21">General recommendations and considerations for a zEC12 and
zBC12 server</a>,
adhere to the <a href="e0z3m100.htm#znextres21">Restrictions for a zEC12 or zBC12 server</a>, and
perform the tasks described in the various topics below.</p>
<h4 id="znextrec21">General recommendations and considerations for a zEC12 and
zBC12 server</h4>
<p>As you plan your migration to a zEnterprise&reg; server, consider the following:</p>
<ol type="1">
<li><strong>Relatively few migration actions are new when coming from a
z196, z114, z10 EC or a z10 BC server.</strong> Migration to an
IBM zEnterprise EC12 or zEnterprise BC12 server has, as its base,
a migration to the z196 or z114 servers. This means that if you are
migrating to a zEnterprise server
from a z196 or z114 server, and have performed the migration actions
associated with the z196 or z114, you have fewer migration actions
than if you were migrating from an earlier generation server and have
not yet performed the migration actions associated with these servers.
There are, in fact, very few new migration actions to perform on z/OS for a zEnterprise zEC12 or zBC12 server if
you have already migrated to a z196 or z114 server. It is important
to note that you can migrate directly to a zEC12 or zBC12 server without
installing the intermediate servers, but you still need to ensure
that any migration considerations are satisfied for the servers that
you &quot;skipped.&quot; To read about z196, z114, z10 EC
and z10 BC server migration actions,
see <a href="e0z3m100.htm#mignext">Migrate to an IBM zEnterprise z196 or z114 server</a> and <a href="e0z3m100.htm#migrz10">Migrate to a System z10 server</a>.</li>
<li><strong>Support is delivered by service and web deliverables.</strong> The
base support for an IBM zEnterprise EC12 or zBC12 server is delivered
by service (PTFs). The PSP bucket that contains the required list
of PTFs is:
<pre class="xmp"><code>Upgrade 2827DEVICE, Subset 2827/ZOS</code></pre>identified
by the following SMP/E Fix Category <samp class="xph">IBM.Device.Server.zEC12-2827</samp>. 

<p>Some
exploitation is delivered by service (PTFs) and is listed in the same
PSP bucket. Other exploitation requires a web deliverable to be downloaded
and installed. The cryptographic support for the zEC12 and zBC12 server
continues to be delivered as a web deliverable packaged as an FMID.
Depending on the cryptographic functions that you want to use, you
might be able to use earlier cryptographic web deliverables.</p>

<p>For
Flash Express&reg; support (including
dynamic reconfiguration support and optional PLPA/COMMON page data
set support), pageable 1 MB Large Page support, and 2 GB Large Page
Support, a separate web deliverable (the z/OS V1R13 or later?????? RSM Enablement Offering
web deliverable) is required. (See &quot;Decide on the steps you will
take for your migration to a zEC12 or zBC12 server&quot; in <a href="e0z3m100.htm#znextbef21">Actions you can take before you order a zEC12 or zBC12 server</a> for further information.)</p></li>
<li><strong>Larger coupling facility structure sizes might be
necessary.</strong> When you change coupling facility control code (CFCC)
levels, your coupling facility structure sizes might change. zEC12
servers that are ordered before September 2013 initially ship with
CFCC level 18, zEC12 or zBC12 models ordered after September 2013
initially ship with CFCC level 19. If, as part of your migration to
a zEC12 or zBC12 server, you change CFCC levels, you might have larger
structure sizes than you did previously. If your CFCC levels are identical,
structure sizes are not expected to change when you migrate from a
previous server to a newer generation server. In addition, similar
to CF Level 17 and later, ensure that the CF LPAR has at least 512MB
of storage. CFLEVEL 19 introduces support for storage-class (flash)
memory in the CF and Coupling thin interrupt support. CF structures
that exploit SCM may require significantly more CF real storage than
they did before storage class memory exploitation.</li>
<li><strong>Use the same software level throughout a sysplex.</strong> Having
members of a sysplex at the same software level (other than during
brief migration periods) is good software management policy.</li>
<li><strong>Migrate hardware and software at different times.</strong> To minimize
the amount of change (and therefore risk) that you experience at one
time, do not migrate your software release level at the same time
that you migrate your hardware.</li>
<li><strong>Update SCRT to latest version.</strong> If you use SCRT, make sure
it is at the latest level. This is a requirement for sub-capacity
pricing, as well as when you upgrade servers. The latest level of
SCRT can be downloaded from the SCRT web site at <a href=" http://www.ibm.com/systems/z/resources/swprice/subcap/scrt/">http://www.ibm.com/eserver/zseries/swprice/scrt/</a>.</li></ol>
<h4 id="znextres21">Restrictions for a zEC12 or zBC12 server</h4>
<p>Restrictions associated with zEnterprise servers
are:</p>
<ol type="1">
<li><strong>Functional limitations</strong>: Not all zEC12 or zBC12
functions are available in every z/OS release. See the following and
for a list of the zEC12 and zBC12 functions available in each z/OS
release.: 

<ul>
<li><a href="e0z3m100.htm#znext21__znextfuncbc">Table 6</a></li>
<li><a href="e0z3m100.htm#znext21__znextbcexp1">Table 7</a></li></ul> Some functions have migration or exploitation considerations
(see <a href="e0z3m100.htm#znextbef21">Actions you can take before you order a zEC12 or zBC12 server</a> and <a href="e0z3m100.htm#znextaft21">Migration and exploitation considerations for zEC12 and zBC12
server functions</a>.
)  Many functions are enabled or disabled, based on the presence or
absence of the required hardware and software. If you wish to position
yourself to exploit any new zEC12 or zBC12 functions, you can install
the software and hardware in either order; that is, there is no requirement
to install either software or hardware first to exploit a specific
function. However, because of outage windows and testing considerations,
you might want to consider installing all the required software first,
then upgrading the hardware and, finally, updating your customization
to exploit the new functions.</li>
<li><strong>zEC12 and zBC12 servers in a sysplex</strong>:  

<ul>
<li>A Parallel
Sysplex that contains an zEC12 or zBC12 server either for a z/OS image or a CF image can only
contain other zEC12 or zBC12 servers or zEnterprise z196, z114, z10 EC, or z10 BC
servers.

<p>If you are running z/OS on
any servers earlier than a z10 EC
or z10 BC server, you cannot
add a zEC12 or zBC12 server to that sysplex; that is, you will not
be able to perform rolling IPLs to introduce a zEC12 or zBC12 server
if you have any of the earlier servers either as z/OS images or coupling facility images in the
sysplex.</p>

<p> The earlier servers in the sysplex must be upgraded
to System z10 or later to have
zEC12 or zBC12 servers supported in the sysplex. If you have any z/OS images or coupling facility
images on an earlier server, and you intend to introduce a zEC12 or
zBC12 server into that sysplex, you must migrate those images to a
System z10 (or later) server
before introducing the zEC12 or zBC12 server.</p>

<p>If you are currently
using ESCON CTCs for GRS ring
configurations within a sysplex, consider using XCF signalling in
a GRS ring configuration. XCF sysplex signalling is preferred instead
of GRS CTC connections. Note that ESCON CTCs
are not supported on a zEC12 or zBC12 server and if you choose not
to convert to XCF signalling, you will have to install toleration
maintenance to enable GRS to use FICON&reg; for
GRS ring configurations. This support does not enhance the robustness
of GRS-managed CTCs and the toleration must be installed across GRS
complex. See <a href="e0z3m100.htm#grsficon1">Migrate to GRS-managed FICON CTCs</a>.</p></li>
<li>The Integrated Cluster Bus 4 (ICB-4) Coupling Links are
not supported on a zEC12 or zBC12 CPC. Use 12x InfiniBand coupling
links, which are designed to replace Integrated Cluster Bus 4 (ICB-4),
and to complement 1x InfiniBand and ISC-3 on a zEC12 or zBC12 server.
InfiniBand coupling can provide significantly improved service times
compared to ISC-3s for distances up to 150 meters. You can read about
InfiniBand coupling links in <em>IBM System z Connectivity Handbook</em> (SG24-5444).</li>
<li>The zEC12 or zBC12 server <strong>cannot</strong> be connected
to a Sysplex Timer&reg; (9037-002).
The Server Time Protocol (STP) feature is the follow-on to the Sysplex Timer. STP is
designed to allow multiple servers and coupling facilities to maintain
time synchronization with each other without requiring a Sysplex Timer. STP is a hardware feature
of the zEC12, z196, z114, z10 EC,
and z10 BC. To implement STP,
see the STP web site and the publications and other resources listed
there. See <a href="./sttostp1.html">Migrate from a Sysplex
Timer to STP</a>. The STP web
site is at <a href="http://www.ibm.com/systems/z/advantages/pso/stp.html">http://www.ibm.com/systems/z/advantages/pso/stp.html </a>. 

<p>The
STP design introduced a concept called Coordinated Timing Network
(CTN). A CTN is a collection of servers and coupling facilities that
are time-synchronized to a time value called Coordinated Server Time.
A CTN can be configured in two ways: 
</p>
<ul>
<li>STP-only CTN, which does not require a Sysplex Timer.</li>
<li>Mixed-CTN (External Time Reference and STP), which does require
a Sysplex Timer. 

<p>The Sysplex Timer provides
the timekeeping information in a Mixed-CTN. Even though the zEC12
or zBC12 servers do not support attachment to a Sysplex Timer, they can participate
in a Mixed-CTN that has a z10 server
synchronized to the Sysplex
Timer. This maintains the capability for enterprises to concurrently
migrate from an existing External Time Reference (ETR) to a Mixed-CTN
and from a Mixed-CTN to an STP-only CTN.</p></li></ul> 

<p></p>
<div>
<div class="note-noindent" id="wq85">
<span class="notetitle">Note:</span> <span class="notebody">The zEC12 and zBC12 will be the last high-end servers
to support connections to an STP Mixed-CTN. All servers in the network
must be configured in STP-only mode. Consider migrating your servers
that require time synchronization, such as to support a base or Parallel
Sysplex(R), to the Server Time Protocol (STP).</span></div></div></li></ul></li>
<li>For a list of functions on the zEC12 or zBC12 server
that are planned to be discontinued on future servers, see <a href="e0z3m100.htm#z2012hw1">Accommodate functions for the zEC12 and zBC12 servers to be
discontinued on future servers</a></li>
<li><strong>Unsupported hardware features</strong>: The following hardware
features <strong>cannot</strong> be ordered  (and cannot be carried forward
from an upgrade on an earlier server to the zEC12 or zBC12 server.
 

<ul id="znextres21__powersequencecontrollerpsc.ficonexp">
<li>Power&reg; Sequence Controller
(PSC).</li>
<li>FICON Express. You should begin migrating to FICON Express8S channels.</li>
<li>FICON Express2. You should
begin migrating to FICON Express8S
channels.</li>
<li>FICON Express4 4KM LX.
You should begin migrating to FICON Express8S
channels.</li>
<li>OSA Express2. You should begin migrating to OSA-Express4S (GbE
LX and SX, 1000BASE-T, 10 GbE LR and SR).</li>
<li>ESCON. You should begin
migrating to FICON Express8S
channels.</li>
<li>Dial up modems. The currently available Network Time Protocol
(NTP) server option for ETS, as well as Internet time services available
using broadband connections, can be used to provide the same degree
of accuracy as dial-up time services. You should begin migrating from
dial-up modems to broadband for RSF connections</li></ul>

<p><strong>Carry forward hardware features</strong>: The following
hardware features are not orderable on zEC12 or zBC12 servers. If
they are installed on your existing server at the time of an upgrade
to a zEC12 or zBC12 server, they may be retained or carried forward.
 
</p>
<ul>
<li>ISC-3. You should begin migrating from ISC-3 features (#0217,
#0218, #0219) to 12x InfiniBand (#0163 - HCA2-O or #0171- HCA3-O fanout)
or 1x InfiniBand (#0168 - HCA2-O LR or #0170 - HCA3-O LR fanout) coupling
links.</li>
<li>FICON Express4 10KM LX.
You should begin migrating to FICON Express8S
channels.</li>
<li>FICON Express4 SX. You
should begin migrating to FICON Express8S
channels</li></ul>

<p>Also, see <a href="e0z3m100.htm#dt2mg230">Ensure you are running on supported servers and storage controllers</a></p></li></ol>
<h4 id="znextbef21">Actions you can take before you order a zEC12 or zBC12 server</h4>
<p>You can perform the following migration actions before you order
or install a zEC12 or zBC12 server:</p>
<ol type="1">
<li><strong>Review the sysplex configuration in which the zEC12
or zBC12 server will participate.</strong> See <a href="e0z3m100.htm#znextres21">Restrictions for a zEC12 or zBC12 server</a> for a description of the
limitations when using zEC12 or zBC12 servers with certain earlier
servers in a Parallel
Sysplex.</li>
<li><strong>Implement STP (or a Mixed-CTN) timing network.</strong> This
action is necessitated because Sysplex Timers (9037-002) are not supported
on zEC12 or zBC12 servers. See <a href="./sttostp1.html">Migrate from a Sysplex
Timer to STP</a>.</li>
<li><strong>Migrate from ICB-4 to InfiniBand coupling links.</strong> This
action is necessitated because ICB-4 links are not supported on  zEC12
or zBC12 servers. If desired, you can take this action after you order
a  zEC12 or zBC12 server, as you upgrade to the new server.</li>
<li><strong>Migrate from unsupported hardware features to newer technology.</strong> This
action is necessitated because FICON Express, FICON Express2, Crypto Express2, and OSA-Express2
10 GbE LR are not supported on zEnterprise servers.
See <a href="e0z3m100.htm#znextres21">Restrictions for a zEC12 or zBC12 server</a>, <a href="e0z3m100.htm#at3ruio">Replace unsupported devices</a>, and <a href="e0z3m100.htm#au3ndv">Provide for new device installations</a>.</li>
<li><em></em><strong>Install the necessary z/OS service, as indicated in PSP buckets.</strong> 

<ul>
<li>For an IBM zEnterprise BC12 CPC. PTFs are identified in the in
the <samp class="xph">2828DEVICE PSP</samp> bucket (<samp class="xph">Subset 2828/ZOS</samp>).</li>
<li>For an IBM zEnterprise EC12 CPC, PTFs are identified in the <samp class="xph">2827DEVICE
PSP</samp> bucket (<samp class="xph">Subset 2827/ZOS</samp>).</li>
<li>For an IBM zEnterprise BladeCenter&reg; Extension (zBX) attached
to your zEC12 CPC or zBC12 CPC, the PTFs are identified in the <samp class="xph">2458DEVICE
PSP</samp> bucket (<samp class="xph">Subset 2458/ZOS</samp>).</li></ul>In each PSP bucket, the content is dependent on the z/OS release
you will run on the zEnterprise server.
If you reviewed the PSP buckets some time ago, review them again to
ensure that any newly identified z/OS service has been installed.
To assist you in determining if you have the recommended service (identified
in these PSP buckets) installed on your system, you can use the SMP/E
REPORT MISSINGFIX command in conjunction with the FIXCAT type of HOLDDATA,
as follows:<a id="idx178"></a><a id="idx179"></a><a id="idx180"></a><a id="idx181"></a>  

<ol type="a">
<li>Acquire and RECEIVE the latest HOLDDATA onto your z/OS system(s). Use your normal service acquisition
portals or download the two (2) year HOLDDATA directly from <a href="http://service.software.ibm.com/holdata/390holddata.html">http://service.software.ibm.com/holdata/390holddata.html</a>.
Ensure you select <strong>Full</strong> from the Download NOW column (last 730
days) to receive the FIXCAT HOLDDATA, as the other files do not contain
FIXCAT HOLDDATA.</li>
<li>Run the SMP/E REPORT MISSINGFIX command on your z/OS systems and specify one or
more of the following Fix Categories (FIXCAT): 

<ul>
<li>IBM.Device.Server.zEC12-2827</li>
<li>IBM.Device.Server.zEC12-2827.Exploitation</li>
<li>IBM.Device.Server..zEC12-2827.ParallelSysplexInfiniBandCoupling</li>
<li>IBM.Device.Server..zEC12-2827.ServerTimeProtocol</li>
<li>IBM.Device.Server..zEC12-2827.zHighPerformanceFICON</li>
<li>IBM.Device.Server..zEC12-2827.UnifiedResourceManager</li>
<li>IBM.Device.Server.zEC12-2827.zEnterpriseDataCompression</li>
<li>IBM.Device.Server.zEC12-2828.Exploitation</li>
<li>IBM.Device.Server.zEC12-2828.zEnterpriseDataCompression</li>
<li>IBM.Device.Server..zEC12-2828.ParallelSysplexInfiniBandCoupling</li>
<li>IBM.Device.Server..zEC12-2828.ServerTimeProtocol</li>
<li>IBM.Device.Server..zEC12-2828.zHighPerformanceFICON</li>
<li>IBM.Device.Server..zEC12-2828.UnifiedResourceManager</li></ul> 

<p>The report will identify any missing coexistence and fallback
PTFs for that system. For complete information about the REPORT MISSINGFIX
command, see <cite>SMP/E for z/OS Commands</cite>.</p></li>
<li>Periodically, you might want to acquire the latest HOLDDATA and
rerun the REPORT MISSINGFIX command to find out if there are any new
PTFs recommended for the zEnterprise servers.</li></ol> 
<div>
<div class="note-noindent" id="wq88">
<span class="notetitle">Note:</span> <span class="notebody">
<ol type="a">
<li>You can also use Service Link's PSP Service Extraction tool.</li>
<li>Because the Enhanced PSP Tool (EPSPT) was removed the end of 2010,
you can no longer use that tool to identify missing PSP bucket service.
You should use SMP/E&rsquo;s Fix Category support, which is fully integrated
into SMP/E procedures and IBM product
and service deliverables.</li></ol></span></div></div></li>
<li><strong>Run CFSIZER and Sizer tools.</strong> If you are moving
your coupling facilities and the coupling facility structures will
be on higher CFCC levels than they were previously, run the Coupling
Facility Structure Sizer (CFSIZER) tool to find out if you have to
increase coupling facility structure sizes.  Run the Sizer utility,
an authorized z/OS program that you can download, to evaluate structure
size changes. The Sizer utility is distinct from CFSizer, and should
be run after the new hardware (CFLEVEL) is installed but before any
CF LPAR on the new hardware is populated with structures. 

<p>If
ordered before September 2013, zEC12 servers initially ship with CFCC
Level 18. For zEC12 and zBC12 servers ordered after September 2013,
the servers ship with CFCC Level 19; prepare to make the necessary
changes as indicated by the tool..</p>

<p>You can find the CFSIZER
tool at <a href=" http://www.ibm.com/systems/support/z/cfsizer/">http://www.ibm.com/systems/support/z/cfsizer/</a>.
Also see <a href="e0z3m100.htm#au3cpfl">Update your CFRM policy with coupling facility structure size
changes</a>.</p>

<p>You can
find the Sizer utility at <a href=" http://www.ibm.com/systems/support/z/cfsizer/">http://www.ibm.com/systems/support/z/cfsizer/altsize.html</a>.</p></li>
<li><strong id="znextbef21__icsfstp1">Decide on the steps you will take for
your migration to a zEC12 or zBC12 server.</strong> In addition to the
steps listed here in <a href="e0z3m100.htm#znextbef21">Actions you can take before you order a zEC12 or zBC12 server</a>,
as a guide, also see <a href="e0z3m100.htm#znextaft21">Migration and exploitation considerations for zEC12 and zBC12
server functions</a>. Also, note the following web
deliverables considerations.

<p>The level of function provided
for cryptographic support differs by z/OS release and the ICSF web
deliverable that is installed. Toleration PTFs are also available
for some cryptographic web deliverables: 
</p>
<ul>
<li>For <strong>z/OS V1R12 and z/OS V1R13 exploitation of zEC12 and zBC12
Crypto Express4S EP11 enhancements</strong> when the Crypto Express4S PCIe
adapter is configured as an EP11 coprocessor (including: PKCS #11
v2.1 PSS, EP11 Key agreement algorithms, and Offload Generation of
Domain Parameters) requires the installation of the <strong>Cryptographic
Support for z/OS V1R12-V1R13 (FMID HCR77A0) or later</strong>. 

<p>Note
that the HCR77A0 level of ICSF IS integrated in z/OS V2R1 and will
be installed as part of a z/OS V2R1 ServerPac.</p></li>
<li>For <strong>z/OS V1R13 and z/OS V2R1 exploitation of zEC12 and zBC12
Crypto Express 4s CCA enhancements </strong>(including: DK AES PIN, Export
TDES key under AES transport key, Diversified Key Generation CBC,
IPEK, RKX key wrapping method, and integration of UDX into CCA) requires
the installation of the <strong>Cryptographic Support for z/OS V1R13-z/OS
V2R1 (FMID HCR77A1) or later</strong>.

<p> Note that the HCR77A1 level of
ICSF IS NOT integrated in z/OS V2R1 ServerPac and must be downloaded
and installed after z/OS V2R1 has been installed.</p></li></ul>

<p>For <strong>z/OS V1R12,</strong> consider
the following: 
</p>
<ul>
<li>If you require <strong>Crypto Express4S toleration</strong>, which treats
Crypto Express4S cryptographic coprocessors and accelerators as Crypto
Express3 coprocessors and accelerators on a zEC12 or zBC12 server,
minimally you must install the toleration PTFs listed in the PSP bucket.</li>
<li>If you require <strong>Crypto Express4S support of X9.8 Pin, 64 Bit,
HMAC, CKDS Constraint Relief, PCI Audit, ECC HW Support, CBC Key Wrap,
and PKA RSA OAEP with SHA-256 algorithm</strong>, minimally you must install
the <strong>Cryptographic Support for z/OS V1R10-V1R12 web deliverable
(FMID HCR7780) or higher</strong>, and a toleration PTF.</li>
<li>If you require <strong>Crypto Express4S support of Expanded key support
for AES algorithm, enhanced ANSI TR-31 Secure Key Exchange, PIN block
decimalization table protection, PKA RSA OAEP with SHA-256 algorithm,
or additional Elliptic Curve Cryptography (ECC) functions</strong>, you
must install the <strong>Cryptographic Support for z/OS V1R11-V1R13 web
deliverable (FMID HCR7790)</strong> and a toleration PTF.</li>
<li>If you require <strong>Crypto Express4S exploitation</strong> including:
Enterprise Security PKCS #11-Hardware Security Module (HSM), DUKPT
for MAC and Data Encryption, Cipher Text Translate CCA Verb, PKDS/TKDS
Constraint Relief, Random Number Cache, FIPS on Demand, or Wrapping
Keys with Strong Keys, you must install the <strong>Cryptographic Support
for z/OS V1R12-V1R13 web deliverable (FMID HCR77A0)</strong>.</li></ul>

<p>For <strong>z/OS V1R13</strong> consider the following:
</p>
<ul>
<li> -	If you require <strong>Crypto Express4S toleration</strong>, which treats
Crypto Express4S cryptographic coprocessors and accelerators as Crypto
Express3 coprocessors and accelerators on a zEC12 or zBC12 server,
minimally you must install the toleration PTFs listed in the PSP bucket.</li>
<li>If you require<strong> Crypto Express4S support of expanded key support
for AES algorithm</strong>, enhanced ANSI TR-31 Secure Key Exchange, PIN
block decimalization table protection, PKA RSA OAEP with SHA-256 algorithm,
or additional Elliptic Curve Cryptography (ECC) functions, you must
install the<strong> Cryptographic Support for z/OS V1R11-V1R13 web deliverable
(FMID HCR7790)</strong> and a toleration PTF.</li>
<li>If you require <strong>Crypto Express4S exploitation</strong> including:
Enterprise Security PKCS #11-Hardware Security Module (HSM), DUKPT
for MAC and Data Encryption, Cipher Text Translate CCA Verb, PKDS/TKDS
Constraint Relief, Random Number Cache, FIPS on Demand, or Wrapping
Keys with Strong Keys, you must install the <strong>Cryptographic Support
for z/OS V1R12-V1R13 web deliverable (FMID HCR77A0)</strong>.</li>
<li>If you require the <strong>Cryptographic Enhancements support for CCA
4.4</strong> (including: DK AES PIN, Export TDES key under AES transport
key, Diversified Key Generation CBC, IPEK, RKX key wrapping method,
and integration of UDX into CCA), you must install the web deliverable <strong>z/OS
V1R13-V2R1 Web deliverable (FMID HCR77A1)</strong>. You must also perform
the required ICSF migration actions. See <a href="e0z3m100.htm#ae1cryp">Cryptographic Services migration actions</a> .</li>
<li>If you want to exploit <strong>Flash Express</strong> (including dynamic
reconfiguration support and optional PLPA/COMMON page data set support,
and pageable 1 MB Large Page support) or <strong>2 GB Large Page Support</strong>,
the <strong>z/OS V1R13 RSM Enablement Offering or z/OS V1R13-V2R1 web deliverable
(FMID JBB778H)</strong> is required. This is a separate web deliverable
from any of the Cryptographic Support web deliverables and can be
installed independently of those web deliverables.</li></ul>

<p>For <strong>z/OS V2R1</strong> consider the following: 
</p>
<ul>
<li>If you require the <strong>cryptographic enhancements support for CCA
4.4 4</strong> (including: DK AES PIN, Export TDES key under AES transport
key, Diversified Key Generation CBC, IPEK, RKX key wrapping method,
and integration of UDX into CCA), you must install the web deliverable <strong>z/OS
V1R13-V2R1 Web deliverable (FMID HCR77A1)</strong>.  You must also perform
the required ICSF migration actions. <a href="e0z3m100.htm#ae1cryp">Cryptographic Services migration actions</a></li>
<li>If you intend to us the<strong> zEDC Express data compression feature</strong>,
then similar to what you might be doing today to enable other z/OS
priced features: you need to notify IBM that you are starting to use
the feature, update the IFAPRDxx PARMLIB member to specify that the
z/OS ZEDC software feature is ENABLED, and follow the z/OS V2R1 documentation
to customize the exploiting functions.  You should also ensure that
all z/OS V1R12 or z/OS V1R13 systems that will access zEDC compressed
data have the required toleration maintenance installed to enable
software decompression.</li></ul>

<p><strong>PTFs for coexistence:</strong> ICSF, specifically HCR7770,
HCR7780, HCR7790, and HCR77A0 require coexistence PTFs to be installed
on earlier levels of ICSF if they share keys in their sysplex. To
assist in identifying the coexistence service, tyou can use he following
Fix Categories: 
</p>
<ul>
<li>IBM.Coexistence.ICSF.z/OS_V1R9-V1R11-HCR7770</li>
<li>IBM.Coexistence.ICSF.z/OS_V1R10-V1R12-HCR7780</li>
<li>IBM.Coexistence.ICSF.z/OS_V1R11-V1R13-HCR7790</li>
<li>IBM.Coexistence.ICSF.z/OS_V1R12-V1R13-HCR77A0</li>
<li>IBM.Coexistence.ICSF.z/OS_V1R13-V2R1-HCR77A1</li></ul></li>
<li><strong>Review the new mnemonics introduced for the zEC12
or zBC12 server.</strong> The new mnemonics might collide with (be identical
to) the names of assembler macro instructions you use or provide.
In the event of such collisions, the HLASM&rsquo;s default opcode table
(UNI) will treat specification of these names as instructions when
APAR PM49761 is installed.  This will probably cause assembler error
messages and possibly cause generation of incorrect object code.  

<p>If
you write programs in Assembler Language, you should compare the list
provided in <cite>z/Architecture Principles
of Operation</cite>, SA22-7832,
to the names of assembler macro instructions you use or provide, to
identify any such conflicts or collisions that would occur following
installation of HLASM APAR PM49761. If a conflict is identified, take
one of the following actions: 
</p>
<ul>
<li>Change the name of your macro instruction.</li>
<li>Specify PARM=&rsquo;...OPTABLE(YOP)...&rsquo; (or some other earlier opcode table).</li>
<li>Specify a separate ASMAOPT file containing assembler options,
such as in the previous method (this method requires no changes to
source code or JCL).</li>
<li>Add, as the first statement of your source program, *PROCESS OPTABLE(YOP).</li>
<li>Specify the PROFILE option either in JCL or the ASMAOPT file,
and the specified or default member of the SYSLIB data set is copied
into the front of the source program.</li>
<li>If you must use both a new instruction and a macro with the same
name in an assembly, you can use the following technique (where XXX
is a sample mnemonic): 
<pre class="xmp"><code>Assume the default OPTABLE(UNI) is in effect
			XXX   a,b       new instruction
			PUSH  ACONTROL  save current optable definition
			ACONTROL OPTABLE(YOP)   switch optable dynamically
			XXX   r,s,t     macro invocation
			POP   ACONTROL  restore previous definition
			XXX   c,d       new instruction</code></pre></li></ul> 

<p>For more information about HLASM&rsquo;s opcode table, see <cite>HLASM Programmer&amp;apos;s Guide</cite>.</p></li>
<li><strong>Plan for changes to your global resource serialization
complex with the zEC12 or zBC12 server. </strong> If you use a global resource
serialization ring complex that spans more systems than is part of
the sysplex or does not use sysplex signalling for communications
within the complex, you need to take migration actions. Instead of
using global resource serialization ring, consider using the global
resource serialization star configuration in a sysplex. You can take
the following actions before you install the zEC12 or zBC12 server: 

<ul>
<li>Migrate to a Parallel
Sysplex that uses the recommended global resource serialization
star complex.</li>
<li>Convert to a basic sysplex that uses XCF sysplex signalling with
global resource serialization ring instead of GRS-managed channel-to-channel
(CTC) communications.</li></ul>Optionally, you can install maintenance for the zEC12 or zBC12
server that provides toleration for FICON-based CTC communications,
but understand that this toleration does not improve the robustness
of GRS-managed CTC communications, and you must install the toleration
maintenance on all systems in the GRS complex. See <a href="e0z3m100.htm#grsficon1">Migrate to GRS-managed FICON CTCs</a>.</li></ol>
<h4 id="znextaft21">Migration and exploitation considerations for zEC12 and zBC12
server functions</h4>
<p>The following zEC12 and zBC12 functions are available on z/OS V1R12, z/OS V1R13, and z/OS
V2R1 releases. For PTF information, see <strong>Notes</strong> to <a href="e0z3m100.htm#znext21__znextbcexp1">Table 7</a>:</p>
<ol type="1">
<li><strong>Consider the number of CPU measurement facility counters for
zEC12 or zBC12</strong>. The number of CPU measurement facility counters
for zEC12 and zBC12 is increased to 80. More extended counters mean
more internal storage is required. While the structure of the SMF
113 Record does not change, the values, interpretations, and frequency
of certain sections do change; therefore, current tools using the
data need to be updated for zEC12 or zBC12. 

<p>For example, consider
the following SMF record fields:  
</p>
<ul>
<li>SMF113_2_CtrVN1 identifies how to interpret the Basic
and Problem counter sets. As described in <cite>The IBM CPU Measurement Facility Extended Counters
Definition for z10 and z196</cite>,
SA23-2260, this field is set to 1 (for z10,
z196, and z114) or 2 (for zEC12/zBC12).</li>
<li>SMF113_2_CtrVN2 identifies how to interpret the Crypto
and Extended counter sets. As described in <cite>The IBM CPU Measurement Facility Extended Counters
Definition for z10 and z196</cite>,
SA23-2260, this field is set to 1 (for z10), 2 (for z196 or z114),
or 3 (for zEC12/zBC12).</li></ul></li>
<li><strong>CFCC Level 19 Coupling thin interrupt support</strong>.
With PTFs provides coupling thin interrupt support that allows a shared
logical coupling facility partition to be dispatched by PR/SM if not
already dispatched and allows for more timely processing of the signal.
This function requires CFCC Level 19.</li>
<li><strong>Cryptographic Enhancements</strong>.  See <strong>Decide on
the steps you will take for your migration to a zEC12 or zBC12 server</strong> in<a href="e0z3m100.htm#znextbef21">Actions you can take before you order a zEC12 or zBC12 server</a></li>
<li><strong>zEDC capability using zEDC Express</strong>.  For z/OS V1R12 and z/OS V1R13 with additional PTFs
(IBM.Device.Server.zEC12-2827.zEnterpriseDataCompression
for EC12 and IBM.Device.Server.zEC12-2828.zEnterpriseDataCompression
for zBC12) provides IBM zEnterprise data compression capability using
zEDC Express for software decompression only. For z/OS V2R1, the full
function requires the z/OS zEDC software feature to be enabled.</li>
<li><strong>LPAR enhancements for WLM/IRD</strong>. Description?</li>
<li><strong>LPAR enhancements for user group capacity limit</strong>. Description?</li>
<li><strong>Add absolute physical hardware LPAR capacity setting</strong>. Description?</li></ol>
<p>The following zEC12 and zBC12 functions are available on z/OS V1R13 and z/OS V2R1 releases.</p>
<ol type="1">
<li><strong>IBM zAware system</strong>. IBM zAware is designed to offer
a real-time, continuous learning, and diagnostics capability intended
to help you pinpoint and resolve potential problems quickly enough
to minimize impacts to your business. After you order a zEC12 or zBC12
you can prepare to set up an IBM zAware
environment by defining the IBM zAware
logical partition, making PARMLIB updates, defining log streams,
and network definitions. For more information, see <cite>IBM System
z Advanced  Workload Analysis Reporter (IBM zAware) Guide</cite>,  (SC27-2623) and <cite>z/OS MVS Setting Up a Sysplex</cite>.</li>
<li><strong> Java Exploitation of Transactional Execution (requires
Java7 SR3)</strong>.  Provides support for Java exploitation
of the Transaction Execution Facility on IBM zEnterprise zEC12 or zBC12.
For z/OS V1R13 the support is intened only for test environments.
This function is designed to help eliminate software locking overhead
that can impact performance. Transactional Execution will offer increased
scalability and parallelism to drive higher transaction throughput. Java exploitation is planned with IBM 31-bit SDK for z/OS, Java technology
Edition, V7.0.0 (5655-W43) and SDK7 IBM 64-bit
SDK for z/OS, Java Technology Edition, V7.0.0 (5655-W44). 

<p>Also
note that the z/OS V1R13 XL
C/C++ compiler when ARCH(10) is specified will provide hardware built-in
functions to enable applications to use the Java Transactional Execution
Facility.</p></li>
<li><strong>Cryptographic Enhancements</strong>.  See <strong>Decide on
the steps you will take for your migration to a zEC12 or zBC12 server</strong> in<a href="e0z3m100.htm#znextbef21">Actions you can take before you order a zEC12 or zBC12 server</a></li>
<li><strong>CF Flash Express (Storage Class Memory or SCM) and 2GB Large
Page support, </strong>. Flash Express (including dynamic reconfiguration
support and optional PLPA/COMMON page data set support, and pageable
1 MB Large Page support) or 2 GB Large Page Support, the z/OS V1R13
RSM Enablement Offering or z/OS V1R13-V2R1 web deliverable (FMID JBB778H)
is required. This is a separate web deliverable from any of the Cryptographic
Support web deliverables and can be installed independently of those
web deliverables.With PTFs and z/OS V1R13 RSM Enablement Offering
Web deliverable for z/OS V1R13 and PTFs for z/OS V2R1 provides CF
Flash SCM exploitation.</li>
<li><strong>New z/Architecture instructions: XL C/C++ ARCH(10) and TUNE(10)
parameters</strong>: with PTFs provides new zArchitecture instructions.</li></ol>
<p>The following zEC12 or zBC12 functions are available on z/OS V2R1: 
</p>
<ol type="1">
<li><strong> Java exploitation of Runtime Instrumentation</strong>.  z/OS V2R1 provides support for Java exploitation of the runtime
instructions on IBM zEnterprise zEC12 and zBC12. This function
requires Java 8.</li>
<li><strong>10GbE RoCE Express</strong>. z/OS V2R1
provides RDMA support for z/OS over converged Enhanced Ethernet Description.</li>
<li><strong>Cryptographic Enhancements</strong>.  See <strong>Decide on
the steps you will take for your migration to a zEC12 or zBC12 server</strong> in<a href="e0z3m100.htm#znextbef21">Actions you can take before you order a zEC12 or zBC12 server</a></li></ol>
<h4 id="z2012hw1">Accommodate functions for the zEC12 and zBC12 servers to be
discontinued on future servers</h4>
<p>[[[[ Technical contact: Marna Walle/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: The following changes in hardware support could
affect your environment. Make appropriate changes as needed. 
</p>
<ul>
<li><strong>STP Mixed CTN</strong>. The zEC12 and zBC12 servers are planned
to be the last high end IBM servers
to support connections to an STP Mixed CTN. This includes the Sysplex Timer (9037).
Future servers that require time synchronization, such as to support
a base or Parallel Sysplex,
will require Server Time Protocol (STP), and all servers in that network
must be configured in STP-only mode.</li>
<li><strong>Removal of support for Ethernet half-duplex operation and 10
Mbps link data rate</strong>. The OSA-Express4S 1000BASE-T Ethernet feature
is planned to be the last copper Ethernet feature to support half-duplex
operation and a 10 Mbps link data rate. The zEC12 and zBC12 servers
are planned to be the last IBM System z servers to support
half-duplex operation and a 10 Mbps link data rate for copper Ethernet
environments. Any future 1000BASE-T Ethernet feature will support
full-duplex operation and auto-negotiation to 100 or 1000 Mbps exclusively.</li>
<li><strong>Removal of ISC-3 support on System
z</strong>. The zEC12 and zBC12 servers are planned to be the last
high-end System z servers
to offer support of the InterSystem Channel-3 (ISC-3) for Parallel Sysplex environments
at extended distances. ISC-3 will not be supported on future high-end System z servers as a carry
forward function on an upgrade. Previously it was announced that the IBM zEnterprise 196 (z196) and IBM zEnterprise 114
(z114) servers were to be the last to offer ordering of ISC-3. Enterprises
should continue migrating from ISC-3 features (#0217, #0218, #0219)
to 12x InfiniBand (#0171 - HCA3-O fanout) or 1x InfiniBand (#0170
- HCA3-O LR fanout) coupling links.</li>
<li><strong>Removal of OSA-Express3 support on System z.</strong> The zEC12 and zBC12 servers
are planned to be the last high-end System
z servers to offer support of the Open System Adapter-Express3
(OSA-Express3 #3362, #3363, #3367, #3370, #3371) family of features.
You should continue to migrate from the OSA-Express3 features to the
OSA-Express4S features (#0404, #0405, #0406, #0407, #0408).</li>
<li><strong>Removal of FICON Express4
support on System z</strong>.
The zEC12 and zBC12 servers are planned to be the last high-end System z servers to offer support
of the FICON Express4 features
(#3321, #3322). You should continue to migrate from the FICON Express4 features to the FICON Express8S features (#0409, #0410).</li>
<li><strong>Removal of Crypto Express3 support on System z</strong>. The zEC12 and zBC12 servers
are planned to be the last high-end System
z servers to offer support of the Crypto Express3 feature (#0864).
You should continue to migrate from the Crypto Express3 feature to
the Crypto Express4S feature (#0865).</li>
<li><strong>IBM System z Application Assist Processor (zAAP)</strong>:
The zEC12 and zBC12 servers are planned to be the last high-end System z servers to offer support
for zAAP specialty engine processors. IBM plans
to converge zAAP and zIIP specialty engines onto zIIPs. This is intended
to help simplify capacity planning and performance management, while
still providing the capability to offload many workloads, which can
help you control software costs.</li></ul>
<div>
<div class="note-noindent" id="wq93">
<span class="notetitle">Note:</span> <span class="notebody">IBM's statements regarding its plans, directions, and intent
are subject to change or withdrawal without notice at IBM's sole discretion.
Information regarding potential future products is intended to outline
our general product direction and it should not be relied on in making
a purchasing decision. The information mentioned regarding potential
future products is not a commitment, promise, or legal obligation
to deliver any material, code, or functionality. Information about
potential future products may not be incorporated into any contract.
The development, release, and timing of any future features or functionality
described for our products remains at our sole discretion</span></div></div>
<table id="wq94" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td> 

<ul>
<li>28 August 2012 in U.S. Announcement Letter for the zEC12.</li>
<li>August 2013???? for the zBC12.</li></ul></td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13
and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before migrating to a zEC12 or zBC12 server.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if you are using a zEC12
or zBC12 server because this is the last server that will support
the changes mentioned in "Description" above.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>See "Description" above.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Take into account the statements in &quot;<strong>Description</strong>&quot;
above as you migrate to zEC12 or zBC12.</p>
<h3 id="mignext">Migrate to an IBM zEnterprise z196 or z114 server</h3>
<p>[[[[ Technical contacts: Gregory Daynes/Poughkeepsie/IBM@IBMUS,
Marna Walle/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: An IBM zEnterprise System includes a Central
Processing Complex (CPC), either the IBM zEnterprise 196 (z196) server
or the IBM zEnterprise 114 (z114) server, or both, the zEnterprise
BladeCenter Extension (zBX) with its integrated optimizers or select
IBM blades, and the zEnterprise Unified Resource Manager (Unified
Resource Manager).</p>
<p>The z114 is an entry-level enterprise server with a smaller
mainframe footprint than the IBM zEnterprise 196 (z196).</p>
<p><a id="idx182"></a><a id="idx183"></a><a id="idx184"></a><a id="idx185"></a><a id="idx186"></a><a id="idx187"></a><a id="idx188"></a><a id="idx189"></a><a id="idx190"></a><a id="idx191"></a><a id="idx192"></a>The specific zEnterprise functions
including base support that are exploited by z/OS depend on the z/OS release, <a href="e0z3m100.htm#mignext__zentfunc2">Table 8</a> lists the z/OS functions that are
included in the base support for the release. <a href="e0z3m100.htm#mignext__zentfexp1">Table 9</a> lists new functions that can be
exploited by the release. For appropriate PTFs that might be required,
see <a href="e0z3m100.htm#znextbef">Actions you can take before you order a z196 and z114 server</a>.</p>
<table id="mignext__zentfunc2" width="100%" summary="" border="1" frame="border" rules="all">
<caption><a href="e0z3m100.htm#FT_Table_8">Table 8. zEnterprise functions included in base z/OS supported for z/OS V1R12, z/OS V1R13, and z/OS V2R1</a></caption>
<thead valign="bottom">
<tr valign="bottom">
<th id="wq95" width="31%" align="left">zEnterprise function included in the base support 

<ul>
<li>Y=Yes</li>
<li>N=No</li></ul></th>
<th id="wq96" width="17%" align="left">V1R12</th>
<th id="wq97" width="17%" align="left">V1R13</th>
<th id="wq98" width="17%" align="left">V2R1</th>
<th id="wq99" width="17%" align="left">Notes</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq95">Base support</td>
<td headers="wq96">Y</td>
<td headers="wq97">Y</td>
<td headers="wq98">Y</td>
<td headers="wq99"></td>
</tr>
<tr>
<td headers="wq95">OSA-Express3 (GbE LX and SX, 1000BASE-T, 10
GbE LR and SR)</td>
<td headers="wq96">Y</td>
<td headers="wq97">Y</td>
<td headers="wq98">Y</td>
<td headers="wq99"></td>
</tr>
<tr>
<td headers="wq95">InfiniBand Coupling Links</td>
<td headers="wq96">Y</td>
<td headers="wq97">Y</td>
<td headers="wq98">Y</td>
<td headers="wq99"></td>
</tr>
<tr>
<td headers="wq95">New z/Architecture&reg; instructions</td>
<td headers="wq96">Y</td>
<td headers="wq97">Y</td>
<td headers="wq98">Y</td>
<td headers="wq99"> 

<p>Support differs by release. z/OS V1R12,
z/OS V1R13, and higher, include XL C/C++ support for ARCH(9) and TUNE(9)
options.</p></td>
</tr>
<tr>
<td headers="wq95">Up to 128 Coupling Links CHPIDs</td>
<td headers="wq96">Y</td>
<td headers="wq97">Y</td>
<td headers="wq98">Y</td>
<td headers="wq99"></td>
</tr>
<tr>
<td headers="wq95">FICON Express8
(CHPID FC)</td>
<td headers="wq96">Y</td>
<td headers="wq97">Y</td>
<td headers="wq98">Y</td>
<td headers="wq99"></td>
</tr>
<tr>
<td headers="wq95">IFAURP reporting</td>
<td headers="wq96">Y</td>
<td headers="wq97">Y</td>
<td headers="wq98">Y</td>
<td headers="wq99"></td>
</tr>
<tr>
<td headers="wq95">Greater than 64 CPs per server</td>
<td headers="wq96">Y (z196 only)</td>
<td headers="wq97">Y (z196 only)</td>
<td headers="wq98">Y (z196 only)</td>
<td headers="wq99"></td>
</tr>
<tr>
<td headers="wq95">Crypto toleration</td>
<td headers="wq96">Y</td>
<td headers="wq97">Y</td>
<td headers="wq98">Y</td>
<td headers="wq99"> 

<p>Support differs depending on level of
ICSF installed. PTF required.</p></td>
</tr>
<tr>
<td headers="wq95">OSA-Express3 (CHPID type OSD) with or without
exploitation of two ports per CHPID</td>
<td headers="wq96">Y</td>
<td headers="wq97">Y</td>
<td headers="wq98">Y</td>
<td headers="wq99"></td>
</tr>
<tr>
<td headers="wq95">Up to 32 HiperSockets&trade;</td>
<td headers="wq96">Y</td>
<td headers="wq97">Y</td>
<td headers="wq98">Y</td>
<td headers="wq99"></td>
</tr>
<tr>
<td headers="wq95">RMF postprocessor
crypto activity report - 4096 bit</td>
<td headers="wq96">Y</td>
<td headers="wq97">Y</td>
<td headers="wq98">Y</td>
<td headers="wq99"></td>
</tr>
<tr>
<td headers="wq95">CPU measurement facility (HIS)</td>
<td headers="wq96">Y</td>
<td headers="wq97">Y</td>
<td headers="wq98">Y</td>
<td headers="wq99"></td>
</tr>
<tr>
<td headers="wq95">Greater than 64 CPs per LPAR</td>
<td headers="wq96">Y (z196 only)</td>
<td headers="wq97">Y (z196 only)</td>
<td headers="wq98">Y (z196 only)</td>
<td headers="wq99"></td>
</tr>
<tr>
<td headers="wq95">HiperDispatch cache and affinity node changes</td>
<td headers="wq96">Y</td>
<td headers="wq97">Y</td>
<td headers="wq98">Y</td>
<td headers="wq99"></td>
</tr>
<tr>
<td headers="wq95">HiperDispatch serviceability</td>
<td headers="wq96">Y</td>
<td headers="wq97">Y</td>
<td headers="wq98">Y</td>
<td headers="wq99"> 

<p>Support differs by release.</p></td>
</tr>
<tr>
<td headers="wq95">LE high register resolution</td>
<td headers="wq96">Y</td>
<td headers="wq97">Y</td>
<td headers="wq98">Y</td>
<td headers="wq99"></td>
</tr>
</tbody>
</table>
<table id="mignext__zentfexp1" width="100%" summary="" border="1" frame="border" rules="all">
<caption><a href="e0z3m100.htm#FT_Table_9">Table 9. zEnterprise functions exploited by z/OS V1R12, z/OS V1R13, and z/OS V2R1</a></caption>
<thead valign="bottom">
<tr valign="bottom">
<th id="wq100" width="31%" align="left"><strong>zEnterprise function: exploitation of z/OS
support</strong> 

<ul>
<li>Y=Yes</li>
<li>N=No</li></ul></th>
<th id="wq101" width="17%" align="left">V1R12</th>
<th id="wq102" width="17%" align="left">V1R13</th>
<th id="wq103" width="17%" align="left">V2R1</th>
<th id="wq104" width="17%" align="left">Notes</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq100">Power save mode</td>
<td headers="wq101">Y (z196 only)</td>
<td headers="wq102">Y (z196 only)</td>
<td headers="wq103">Y (z196 only)</td>
<td headers="wq104"></td>
</tr>
<tr>
<td headers="wq100">OSA-Express4S (GbE LX and SX, and 10 GbE LR
and SR)</td>
<td headers="wq101">Y</td>
<td headers="wq102">Y</td>
<td headers="wq103">Y</td>
<td headers="wq104"></td>
</tr>
<tr>
<td headers="wq100">OSA-Express4S improved port granularity</td>
<td headers="wq101">Y</td>
<td headers="wq102">Y</td>
<td headers="wq103">Y</td>
<td headers="wq104"></td>
</tr>
<tr>
<td headers="wq100">FICON Express8S support of zHPF single track
operations</td>
<td headers="wq101">Y</td>
<td headers="wq102">Y</td>
<td headers="wq103">Y</td>
<td headers="wq104"></td>
</tr>
<tr>
<td headers="wq100">FICON Express8S support of zHPF multi-track
operations</td>
<td headers="wq101">Y</td>
<td headers="wq102">Y</td>
<td headers="wq103">Y</td>
<td headers="wq104"></td>
</tr>
<tr>
<td headers="wq100">Coupling Facility Control Code (CFCC) Level
17</td>
<td headers="wq101">Y</td>
<td headers="wq102">Y</td>
<td headers="wq103">Y</td>
<td headers="wq104"></td>
</tr>
<tr>
<td headers="wq100">Three subchannel sets</td>
<td headers="wq101">Y  (z196 only)</td>
<td headers="wq102">Y  (z196 only)</td>
<td headers="wq103">Y  (z196 only)</td>
<td headers="wq104"></td>
</tr>
<tr>
<td headers="wq100">IPL from alternate subchannel set</td>
<td headers="wq101">Y</td>
<td headers="wq102">Y</td>
<td headers="wq103">Y</td>
<td headers="wq104"></td>
</tr>
<tr>
<td headers="wq100">IBM zEnterprise
Unified Resource Manager</td>
<td headers="wq101">Y</td>
<td headers="wq102">Y</td>
<td headers="wq103">Y</td>
<td headers="wq104"></td>
</tr>
<tr>
<td headers="wq100">IBM zEnterprise BladeCenter Extension (zBX)
 

<p>(Support for OSA CHPID types OSM and OSX.)</p></td>
<td headers="wq101">Y</td>
<td headers="wq102">Y</td>
<td headers="wq103">Y</td>
<td headers="wq104"></td>
</tr>
<tr>
<td headers="wq100">Crypto exploitation of ANSI X9.8 Pin security, enhanced Common
Cryptographic Architecture (CCA), 64 Bit, CP Assist for Cryptographic
Function (CPACF) enhancements, Secure Keyed-Hash Message Authentication
Code (HMAC), CKDS Constraint Relief, PCI Audit, Elliptical Curve Cryptography
(ECC) Digital Signature Algorithm, and CBC Key Wrap, PKA RSA OEAP
with SHA-256.</td>
<td headers="wq101">Y</td>
<td headers="wq102">Y</td>
<td headers="wq103">Y</td>
<td headers="wq104"> 

<p>z/OS V1R12 requires Cryptographic Support
for z/OS V1R10-V1R12 [FMID HCR7780] web deliverable)</p></td>
</tr>
<tr>
<td headers="wq100">Crypto exploitation.  For Crypto Express3 feature when defined
as a coprocessor: expanded support for AES algorithm, enhanced ANSI
TR-31 Secure Key Exchange, PIN block decimalization table protection,
and PKA RSA OAEP with SHA-256 algorithm, additional Elliptic Curve
Cryptography (ECC) functions.</td>
<td headers="wq101">Y</td>
<td headers="wq102">Y</td>
<td headers="wq103">Y</td>
<td headers="wq104"> 

<p>Requires Cryptographic Support for z/OS V1R11-V1R13 [FMID HCR7790
web deliverable available September 2011.</p></td>
</tr>
<tr>
<td headers="wq100">FICON Express8S (CHPID type FC)</td>
<td headers="wq101">Y</td>
<td headers="wq102">Y</td>
<td headers="wq103">Y</td>
<td headers="wq104"></td>
</tr>
<tr>
<td headers="wq100">zHPF performance improvements for FICON Express8S</td>
<td headers="wq101">Y</td>
<td headers="wq102">Y</td>
<td headers="wq103">Y</td>
<td headers="wq104"></td>
</tr>
<tr>
<td headers="wq100">z/OS Discovery and AutoConfiguration (zDAC)
support</td>
<td headers="wq101">Y</td>
<td headers="wq102">Y</td>
<td headers="wq103">Y</td>
<td headers="wq104"></td>
</tr>
<tr>
<td headers="wq100">New OSA display command</td>
<td headers="wq101">Y</td>
<td headers="wq102">Y</td>
<td headers="wq103">Y</td>
<td headers="wq104"></td>
</tr>
<tr>
<td headers="wq100">OSA-Express3 and OSA-Express4S Inbound Workload
Queuing (IWQ)</td>
<td headers="wq101">Y</td>
<td headers="wq102">Y</td>
<td headers="wq103">Y</td>
<td headers="wq104"></td>
</tr>
<tr>
<td headers="wq100">Inbound workload queuing for Enterprise Extender
for the OSA-Express4S and OSA-Express3 features when defined as CHPID
types OSD or OSX</td>
<td headers="wq101">N</td>
<td headers="wq102">Y</td>
<td headers="wq103">Y</td>
<td headers="wq104"></td>
</tr>
<tr>
<td headers="wq100">OSA-Express4S checksum offload for LPAR-to-LPAR
traffic  for IPv4 and IPv6 packets (CHPID type OSD or OSX)</td>
<td headers="wq101">N</td>
<td headers="wq102">Y</td>
<td headers="wq103">Y</td>
<td headers="wq104"></td>
</tr>
<tr>
<td headers="wq100">OSA-Express4S large send for IPv6 packets (CHPID
types OSD and OSX)</td>
<td headers="wq101">N</td>
<td headers="wq102">Y</td>
<td headers="wq103">Y</td>
<td headers="wq104"></td>
</tr>
</tbody>
</table>
<table id="wq105" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td width="25%"><strong>Element or feature</strong>:</td>
<td width="75%">Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td> 

<ul>
<li>The IBM zEnterprise 114
(z114), which shipped in September 2011.</li>
<li>The IBM zEnterprise 196
(z196), which first shipped in September 2010.</li>
<li>The IBM zEnterprise BladeCenter Extension (zBX),
which shipped November 2010.</li></ul></td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V2R1, z/OS V1R13, and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Anytime before you introduce a zEnterprise server
into your environment.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to run z/OS V2R1, V1R13, or V1R12 on a zEnterprise
server, or if you want to run a Coupling Facility on a zEnterprise
server.  If you will run only a Coupling Facility on a zEnterprise
system, then only the sysplex-related actions below are relevant.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td> 

<ul>
<li>A z196 or a z114 server.</li>
<li>Additional hardware required for specific functions. 

<ul>
<li>zDAC requires: 

<ul>
<li>Up-to-date controller microcode</li>
<li>Up-to-date switch microcode</li></ul></li>
<li>IBM zEnterprise Blade Center Extension (zBX) is required for the
IBM Smart Analytics Optimizer for DB2 for z/OS V1.1, the IBM WebSphere
DataPower Integration Appliance XI50 for zEnterprise (DataPower XI50z),
and select POWER7 and IBM System x blades.</li>
<li>An IBM System Storage&reg; DS5020 is required
for IBM Smart Analytics Optimizer.</li></ul></li></ul></td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td> 

<ol type="1">
<li>See the list of PTFs in the Software Service Level section of
the PSP buckets.</li>
<li>See <strong>Install the necessary z/OS service,
as indicated in PSP buckets</strong> described in <a href="e0z3m100.htm#znextrec">General recommendations and considerations for z196 and z114
servers</a>.</li></ol></td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td> 

<ul>
<li>It is recommended that you install and run the zEnterprise required
service on your existing server. This will enable you to fall back
from a hardware perspective, yet maintain your software level.</li>
<li>The PTFs to support CFCC Level 17 have coexistence (or sysplex
preconditioning) PTFs that are required to be installed throughout
your sysplex before implementing CFCC Level 17.</li></ul></td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>See <a href="e0z3m100.htm#znextres">Restrictions for a z196 or z114 server</a>.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>IBM Health
Checker for z/OS check, SUP_HiperDispatchCPUConfig, is added to z/OS
V1R12 and available on z/OS V1R11. This check will verify that HiperDispatch
is enabled on a zEnterprise system. (For more information, see "HiperDispatch
cache and affinity node changes" in <a href="e0z3m100.htm#znextexp">Migration and exploitation considerations for z196 and z114
server functions</a>).
 
<div>
<div class="note-noindent" id="wq107">
<span class="notetitle">Note:</span> <span class="notebody">The default of HIPERDISPATCH option in IEAOPTxx parmlib
member was changed in z/OS V1R13 as follows: 

<ul>
<li>For IBM zEnterprise 196 (and follow-on processors): YES</li>
<li>For IBM System z10 processors: NO</li></ul></span></div></div></td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Follow the <a href="e0z3m100.htm#znextrec">General recommendations and considerations for z196 and z114
servers</a>,
adhere to the <a href="e0z3m100.htm#znextres">Restrictions for a z196 or z114 server</a>, and perform
the tasks described in the various topics below.</p>
<h4 id="znextrec">General recommendations and considerations for z196 and z114
servers</h4>
<p>As you plan your migration to a zEnterprise server, consider the
following:</p>
<ol type="1">
<li><strong>Relatively few migration actions are new when
coming from a z10 EC or a z10 BC server.</strong> Migration to
a zEnterprise server
has, as its base, a migration to the z10 EC
or z10 BC servers. This means
that if you are migrating to a zEnterprise server
from a z10 EC or z10 BC server, and have performed the migration actions
associated with the z10 EC or z10 BC, you have fewer migration
actions than if you were migrating from a server prior to the z10 EC or z10 BC and have not yet performed the migration actions
associated with these servers. There are, in fact, very few new migration
actions to perform on z/OS for
a zEnterprise server
if you have already migrated to a z10 EC
or z10 BC server. It is important
to note that you can migrate directly to a zEnterprise server without installing the intermediate
servers, but you still need to ensure that any migration considerations
are satisfied for the servers that you &quot;skipped.&quot; To read about z10 EC and z10 BC server migration actions, see <a href="e0z3m100.htm#migrz10">Migrate to a System z10 server</a>.</li>
<li><strong>Support is delivered by service (and FMID web
deliverables for ICSF).</strong> The delta (from a z10 EC or z10 BC)
support for a zEnterprise server, excluding cryptographic support,
is delivered by service (PTFs).  The cryptographic support for the
zEnterprise server continues to be FMIDs, many of which are still
available in web deliverables. Different ICSF web deliverables, providing
different levels of support, are available for different releases
of z/OS. (See &quot;Decide on the steps you will take for your migration
to a zEnterprise server&quot; in <a href="e0z3m100.htm#znextbef">Actions you can take before you order a z196 and z114 server</a> for further
information.)</li>
<li><strong>Larger coupling facility structure sizes might
be necessary.</strong> When you change coupling facility control code
(CFCC) levels, your coupling facility structure sizes might change.
zEnterprise servers initially ship with CFCC level 17. If, as part
of your migration to a zEnterprise server, you change CFCC levels
(either by placing a coupling facility on the zEnterprise server or
by moving the coupling facility to a z10 EC
or z10 BC at a later CFCC level),
you might have larger structure sizes than you did previously. If
your CFCC levels are identical, structure sizes are not expected to
change when you migrate from a previous server to a newer generation
server.</li>
<li><strong>Use the same software level throughout a sysplex.</strong> Having
members of a sysplex at the same software level (other than during
brief migration periods) is good software management policy.</li>
<li><strong>Migrate hardware and software at different times.</strong> To
minimize the amount of change (and therefore risk) that you experience
at one time, do not migrate your software release level at the same
time that you migrate your hardware.</li>
<li><strong>Update SCRT to latest version.</strong> If you use
SCRT, make sure it is at the latest level. This is a requirement for
vWLC, as well as when you upgrade servers. The latest level of SCRT
can be downloaded from the SCRT web site at <a href=" http://www.ibm.com/systems/z/resources/swprice/subcap/scrt/">http://www.ibm.com/eserver/zseries/swprice/scrt/</a>.</li></ol>
<h4 id="znextres">Restrictions for a z196 or z114 server</h4>
<p>Restrictions associated with zEnterprise servers are:</p>
<ol type="1">
<li><strong>Functional limitations</strong>: Not all zEnterprise functions are
available in every z/OS release. See <a href="e0z3m100.htm#mignext__zentfunc2">Table 8</a> and <a href="e0z3m100.htm#mignext__zentfexp1">Table 9</a> for a list of the zEnterprise
functions available in each z/OS release. Some functions have migration
or exploitation considerations (see <a href="e0z3m100.htm#znextexp">Migration and exploitation considerations for z196 and z114
server functions</a>).
 Many functions are enabled or disabled, based on the presence or
absence of the required hardware and software. If you wish to position
yourself to exploit any new zEnterprise functions, the software and
hardware may be installed in either order. That is, there is no requirement
to install either software or hardware first to exploit a specific
function. However, due to outage windows and testing considerations,
you might want to consider installing all the required software first,
then upgrading the hardware and, finally, updating your customization
to exploit the new functions.</li>
<li><strong>zEnterprise servers
in a sysplex</strong>:  

<ul>
<li>zEnterprise servers
z196 and z114 are supported in a Parallel Sysplex with other zEnterprise z196 and z114
servers, z10 EC and z10 BC servers, and z9 EC
and z9 BC servers.  If you introduce
zEC12 or zBC12 into a sysplex with z196 or z114, ensure that you have
satisfied the zEC12 or zBC12 sysplex restrictions in <a href="e0z3m100.htm#znextres21">Restrictions for a zEC12 or zBC12 server</a>. If you are running z/OS on zSeries z900, z800, z990, or z890 servers,
then you cannot add a zEnterprise z196
and z114 server to that sysplex. That is, you will not be able to
perform rolling IPLs to introduce a zEnterprise z196 and z114 server if you
have any of the earlier (pre-System z) servers either as z/OS images or coupling facility images in the
sysplex. The earlier servers in the sysplex must be upgraded to System z9 or later to have zEnterprise z196 and z114 servers supported
in the sysplex. If you have any z/OS images
or coupling facility images on an earlier server, and you intend to
introduce a zEnterprise z196
and z114 server into that sysplex, you must migrate those images to
System z9 (or later) server before
introducing the zEnterprise z196
and z114 server.</li>
<li>The Integrated Cluster Bus 4 (ICB-4) Coupling Links are not supported
on a zEnterprise CPC.
Use 12x InfiniBand coupling links, which are designed to replace Integrated
Cluster Bus 4 (ICB-4), and to complement 1x InfiniBand and ISC-3 on
a zEnterprise server.
InfiniBand coupling can provide significantly improved service times
compared to ISC-3s for distances up to 150 meters. You can read about
InfiniBand coupling links in <em>IBM System z Connectivity Handbook</em> (SG24-5444).</li>
<li>The zEnterprise servers <strong>cannot</strong> be
connected to a Sysplex
Timer (9037-002). The Server Time Protocol (STP) feature is the
follow-on to the Sysplex
Timer. STP is designed to allow multiple servers and coupling
facilities to maintain time synchronization with each other without
requiring a Sysplex Timer.
STP is a hardware feature of the zEnterprise, z10 EC, z10 BC, z9 EC, z9 BC,
z990, and z890 servers. To implement STP, see the STP web site and
the publications and other resources listed there. The STP web site
is at <a href="http://www.ibm.com/systems/z/advantages/pso/stp.html">http://www.ibm.com/systems/z/advantages/pso/stp.html </a>. 

<p>The
STP design introduced a concept called Coordinated Timing Network
(CTN). A CTN is a collection of servers and coupling facilities that
are time-synchronized to a time value called Coordinated Server Time.
A CTN can be configured in two ways: 
</p>
<ul>
<li>STP-only CTN, which does not require a Sysplex Timer.</li>
<li>Mixed-CTN (External Time Reference and STP), which does require
a Sysplex Timer. 

<p>The Sysplex Timer provides
the timekeeping information in a Mixed-CTN. Even though the zEnterprise servers do not
support attachment to a Sysplex
Timer, they can participate in a Mixed-CTN that has either a z10 or z9 server
synchronized to the Sysplex
Timer. This maintains the capability for enterprises to concurrently
migrate from an existing External Time Reference (ETR) to a Mixed-CTN
and from a Mixed-CTN to an STP-only CTN.</p></li></ul></li></ul></li>
<li><strong>Unsupported hardware features</strong>: The following hardware features
that were available on System z10 (and
some earlier) servers <strong>cannot</strong> be ordered (and cannot be
carried forward on an upgrade to a z114) server with zEnterprise servers. You must migrate
to the newer technology available on zEnterprise servers. 

<ul>
<li>FICON Express</li>
<li>FICON Express2</li>
<li>Crypto Express2</li>
<li>OSA-Express2 10 GbE LR</li></ul> 

<p>The following hardware features are not orderable on z196
servers. If they are installed on your existing server at the time
of an upgrade to a z196 server, they may be retained. 
</p>
<ul>
<li>FICON Express4 10KM LX</li>
<li>FICON Express4 SX</li>
<li>FICON Express4 4KM LX</li>
<li>OSA-Express2 GbE LX</li>
<li>OSA-Express2 GbE SX</li>
<li>OSA-Express2 1000BASE-T</li></ul> 

<p>The following hardware features are not orderable on
z114 servers. If they are installed on your existing server at the
time of an upgrade to a z114 server, they may be retained. 
</p>
<ul>
<li>FICON Express4 10KM LX</li>
<li>FICON Express4 SX</li>
<li>FICON Express4 4KM LX</li>
<li>FICON Express4-2C 4KM
LX</li>
<li>FICON Express4-2C SX</li>
<li>OSA-Express2 GbE LX</li>
<li>OSA-Express2 GbE SX</li>
<li>OSA-Express2 1000BASE-T</li></ul></li></ol>
<h4 id="znextbef">Actions you can take before you order a z196 and z114 server</h4>
<p>You can perform the following migration actions before you order
or install a zEnterprise server:</p>
<ol type="1">
<li><strong>Review the sysplex configuration in which the zEnterprise server will participate.</strong> See <a href="e0z3m100.htm#znextres">Restrictions for a z196 or z114 server</a> for a description of the limitations
when using IBM zEnterprise EC12 servers with zEnterprise z196 or z114 servers or with
other earlier servers in a Parallel
Sysplex.</li>
<li><strong>Implement STP (or a Mixed-CTN) timing network.</strong> This action
is necessitated because Sysplex Timers (9037-002) are not supported
on zEnterprise servers.</li>
<li><strong>Migrate from ICB-4 to InfiniBand coupling links.</strong> This action
is necessitated because ICB-4 links are not supported on zEnterprise
servers. If desired, you can take this action after you order a zEnterprise
server, as you upgrade to the new server.</li>
<li><strong>Migrate from unsupported hardware features to newer technology.</strong> This
action is necessitated because FICON Express, FICON Express2, Crypto Express2, and OSA-Express2
10 GbE LR are not supported on zEnterprise servers.</li>
<li><em></em><strong>Install the necessary z/OS service,
as indicated in PSP buckets.</strong> For a zEnterprise 196 CPC, PTFs are identified
in the 2817DEVICE PSP bucket (Subset 2817/ZOS). For a zEnterprise 114 CPC, PTFs are identified
in the 2818DEVICE PSP bucket (Subset 2818/ZOS). For an IBM zEnterprise BladeCenter Extension (zBX) attached
to your z196 CPC or to your z114 CPC, the PTFs are identified in the
2458DEVICE PSP bucket (Subset 2458/ZOS). In each PSP bucket, the content
is dependent on the z/OS release
you will run on the zEnterprise server.
If you reviewed the PSP buckets some time ago, review them again to
ensure that any newly identified z/OS service
has been installed. To assist you in determining if you have the recommended
service (identified in these PSP buckets) installed on your system,
you can use the SMP/E REPORT MISSINGFIX command in conjunction with
the FIXCAT type of HOLDDATA, as follows:<a id="idx193"></a><a id="idx194"></a><a id="idx195"></a><a id="idx196"></a>  

<ol type="a">
<li>Acquire and RECEIVE the latest HOLDDATA onto your z/OS system(s). Use your normal service acquisition
portals or download the two (2) year HOLDDATA directly from <a href="http://service.software.ibm.com/holdata/390holddata.html">http://service.software.ibm.com/holdata/390holddata.html</a>.
Ensure you select <strong>Full</strong> from the Download NOW column (last 730
days) to receive the FIXCAT HOLDDATA, as the other files do not contain
FIXCAT HOLDDATA.</li>
<li>Run the SMP/E REPORT MISSINGFIX command on your z/OS systems and specify one or more of the
following Fix Categories (FIXCAT): 

<ul>
<li>IBM.Device.Server.z196-2817</li>
<li>IBM.Device.Server.z196-2817.ParallelSysplexInfiniBandCoupling</li>
<li>IBM.Device.Server.z196-2817.ServerTimeProtocol</li>
<li>IBM.Device.Server.z196-2817.zHighPerformanceFICON</li>
<li>IBM.Device.Server.z114-2818</li>
<li>IBM.Device.Server.z114-2818.ParallelSysplexInfiniBandCoupling</li>
<li>IBM.Device.Server.z114-2818.ServerTimeProtocol</li>
<li>IBM.Device.Server.z114-2818.zHighPerformanceFICON</li>
<li>IBM.Device.Server.z114-2818.UnifiedResourceManager</li>
<li>IBM.Device.Server.zBX-2458</li>
<li>IBM.Device.Server.zBX-2458.ISAOPT</li></ul> 

<p>The report will identify any missing coexistence and fallback
PTFs for that system. For complete information about the REPORT MISSINGFIX
command, see <cite>SMP/E for z/OS Commands</cite>.</p></li>
<li>Periodically, you might want to acquire the latest HOLDDATA and
rerun the REPORT MISSINGFIX command to find out if there are any new
PTFs recommended for the zEnterprise servers.</li></ol> 
<div>
<div class="note-noindent" id="wq112">
<span class="notetitle">Note:</span> <span class="notebody">
<ol type="a">
<li>You can also use Service Link's PSP Service Extraction tool.</li>
<li>Because the Enhanced PSP Tool (EPSPT) was removed the end of 2010,
you can no longer use that tool to identify missing PSP bucket service.
You should use SMP/E&rsquo;s Fix Category support, which is fully integrated
into SMP/E procedures and IBM product
and service deliverables.</li></ol></span></div></div></li>
<li><strong>Run CFSIZER and Sizer tools.</strong> If you are moving
your coupling facilities and the coupling facility structures will
be on higher CFCC levels than they were previously, run the Coupling
Facility Structure Sizer (CFSIZER) tool to find out if you have to
increase coupling facility structure sizes.  Run the Sizer utility,
an authorized z/OS program that you can download, to evaluate structure
size changes. The Sizer utility is distinct from CFSizer, and should
be run after the new hardware (CFLEVEL) is installed but before any
CF LPAR on the new hardware is populated with structures. zEnterprise servers are initially
shipped with CFCC Level 17; prepare to make the necessary
changes as indicated by the tool. You can find the CFSIZER tool at <a href=" http://www.ibm.com/systems/support/z/cfsizer/">http://www.ibm.com/systems/support/z/cfsizer/</a>.</li>
<li><strong>Plan for the fixed HSA enhancement on a zEnterprise server.</strong> On
zEnterprise (and z10) servers,
preplanning requirements are minimized by offering a fixed HSA and
introduction of the ability to seamlessly include such events as creation
of LPARs, inclusion of logical subsystems, changing logical processor
definitions in an LPAR, and introduction of cryptography into an LPAR.</li>
<li><strong id="znextbef__icsfstp">Decide on the steps you will take for your migration
to a zEnterprise server.</strong> 
As a guide, see <a href="e0z3m100.htm#znxtrmss">Recommended migration steps for a z196 and z114 server</a>. Also,
note the following: 

<ul>
<li>You should compare the cryptographic support you currently have
installed with the support required for the functions you plan to
use on the zEnterprise z196
and z114 server. Several cryptographic support web deliverables have
been made available for various z/OS releases.
When a subsequent cryptographic web deliverable is available for a
particular z/OS level, the
previous one is withdrawn. The newer cryptographic web deliverable,
however, includes the previous function (when applicable) for that
particular z/OS level. Note
that you can use the newer cryptographic web deliverables on servers
before the zEnterprise servers,
that is, on z10 and z9 (or earlier) servers.</li>
<li>The level of function provided for cryptographic support differs
by z/OS release and the ICSF
web deliverable that is installed.  For z/OS V1R12
and later, exploitation of zEnterprise z196
and z114 cryptographic support is provided by Cryptographic Support
for z/OS V1R11-V1R13 (FMID
HCR7790), web deliverable (the z/OS Lifecycle
Extension for z/OS V1.11 (5657-A01)
is required for support after September 2012).  Note that this
level of ICSF is <strong>not</strong> integrated in z/OS V1R13 and will need to be downloaded and
installed even after ordering a z/OS V1R13
ServerPac.   

<p>For z/OS V1R12, exploitation of the original zEnterprise cryptographic
enhancements was provided by the Cryptographic Support for z/OS V1R10-V1R12 web deliverable
(FMID HCR7780), which is integrated into z/OS V1R13 orders. The Cryptographic web deliverables
are available at <a href=" http://www.ibm.com/systems/z/os/zos/downloads/">http://www-03.ibm.com/systems/z/os/zos/downloads/</a> 
</p>
<ul>
<li>Coexistence PTFs are available for all supported z/OS releases and all existing supported ICSF
web deliverables.</li>
<li>For z/OS V1R12: If you require ANSI X9.8 Pin security, enhanced
Common Cryptographic Architecture (CCA), 64 Bit, CP Assist for Cryptographic
Function (CPACF) enhancements, Secure Keyed-Hash Message Authentication
Code (HMAC), CKDS Constraint Relief, PCI Audit, Elliptical Curve Cryptography
(ECC) Digital Signature Algorithm, and CBC Key Wrap, PKA RSA OEAP
with SHA-256, then minimally you must install the Cryptographic Support
for z/OS V1R10-V1R12 web deliverable
(FMID HCR7780), which is integrated into z/OS V1R13 orders.</li>
<li>For z/OS V1R12
and later releases: For Crypto Express3 feature when defined as a
coprocessor: expanded support for AES algorithm, enhanced ANSI TR-31
Secure Key Exchange, PIN block decimalization table protection, and
PKA RSA OAEP with SHA-256 algorithm, additional Elliptic Curve Cryptography
(ECC) functions. You must install the Cryptographic Support for z/OS V1R11-V1R13 web deliverable
(FMID HCR7790), available September 2011.</li></ul><p class="indatacontent"> </p>
<div>
<div class="note-noindent" id="wq114">
<span class="notetitle">Note:</span> <span class="notebody"> ICSF, specifically HCR7770, HCR7780, <span>and
HCR7790</span>, require coexistence PTFs to be installed on earlier
levels of ICSF if they share keys in their sysplex. To assist in identifying
the coexistence service, the following Fix Categories can be used:
 

<ul>
<li>IBM.Coexistence.ICSF.z/OS_V1R9-V1R11-HCR7770</li>
<li>IBM.Coexistence.ICSF.z/OS_V1R10-V1R12-HCR7780</li>
<li>IBM.Coexistence.ICSF.z/OS_V1R11-V1R13-HCR7790</li></ul></span></div></div></li></ul></li>
<li><strong>Review the new mnemonics introduced for the zEnterprise server.</strong> The
new mnemonics might collide with (be identical to) the names of assembler
macro instructions you use or provide. In the event of such collisions,
the HLASM&rsquo;s default opcode table (UNI) will treat specification of
these names as instructions when APAR PK97799 is installed.  This
will probably cause assembler error messages and possibly cause generation
of incorrect object code.  

<p>If you write programs in assembler language,
you should compare the list provided in <cite>z/Architecture
Principles of Operation</cite>, SA22-7832, to the names of assembler
macro instructions you use or provide, to identify any such conflicts
or collisions that would occur following installation of HLASM APAR
PK97799. If a conflict is identified, take one of the following actions: 
</p>
<ul>
<li>Change the name of your macro instruction.</li>
<li>Specify PARM=&rsquo;...OPTABLE(YOP)...&rsquo; (or some other earlier opcode table).</li>
<li>Specify a separate ASMAOPT file containing assembler options,
such as in the previous method (this method requires no changes to
source code or JCL).</li>
<li>Add, as the first statement of your source program, *PROCESS OPTABLE(YOP).</li>
<li>Specify the PROFILE option either in JCL or the ASMAOPT file,
and the specified or default member of the SYSLIB data set is copied
into the front of the source program.</li>
<li>If you must use both a new instruction and a macro with the same
name in an assembly, you can use the following technique (where XXX
is a sample mnemonic): 
<pre class="xmp"><code>Assume the default OPTABLE(UNI) is in effect
			XXX   a,b       new instruction
			PUSH  ACONTROL  save current optable definition
			ACONTROL OPTABLE(YOP)   switch optable dynamically
			XXX   r,s,t     macro invocation
			POP   ACONTROL  restore previous definition
			XXX   c,d       new instruction</code></pre></li></ul> 

<p>For more information about HLASM&rsquo;s opcode table, see <cite>HLASM Programmer&amp;apos;s Guide</cite>.</p></li></ol>
<h4 id="znextaft">Actions you can take after you order a z196 and z114 server</h4>
<p>After you order but before you install your zEnterprise server,
do the following:</p>
<ol type="1">
<li><strong>Use the CHPID Mapping Tool.</strong> As you might
have done with your z10 EC, z10 BC, z9 EC
or z9 BC servers, use the CHPID
Mapping Tool to map logical CHPIDs to physical channels (PCHIDs) and
create input to HCD/IOCP for your zEnterprise server. The tool is
a workstation-based Java application
available from the Resource Link&reg; web site (<a href=" http://www.ibm.com/servers/resourcelink">http://www.ibm.com/servers/resourcelink</a>).
For more information about this tool, refer to the web site.</li>
<li><strong>Define an Ensemble.</strong> If you are running z/OS V1R10 or later, you can define
an Ensemble and exploit the IBM zEnterprise
Unified Resource Manager. See <em>System z Ensemble Planning and Configuration Guide</em> (GC27-2608)
for a detailed description of the steps required to define an Ensemble.</li></ol>
<h4 id="znxtrmss">Recommended migration steps for a z196 and z114 server</h4>
<p>This topic suggests the steps for migrating your same z/OS release level from your current server
to a zEnterprise server. The steps are based on the assumption that
you want to minimize the amount of change (and therefore risk) and
the amount of work required to perform the migration.</p>
<p>Your migration steps follow:</p>
<ol type="1">
<li>If necessary, migrate to an STP-only or Mixed-CTN timing network.</li>
<li>Ensure that you have installed the z196, z114, z10 EC (or z10 BC), and z9 EC
(or z9 BC) required service,
as indicated in the respective PSP buckets. See <strong>Install the necessary z/OS service, as indicated in PSP
buckets</strong> in <a href="e0z3m100.htm#znextbef">Actions you can take before you order a z196 and z114 server</a> for information
about how to identify, acquire, and install any missing required service.</li>
<li>Ensure you have the required service, and any required ICSF web
deliverable installed for the cryptographic functions that you have
decided to use.</li>
<li>Upgrade your hardware to zEnterprise system. If necessary convert
to InfiniBand Coupling Links from ICB-4 links.</li>
<li>Update configuration setting to exploit zEnterprise functions.</li></ol>
<h4 id="znextexp">Migration and exploitation considerations for z196 and z114
server functions</h4>
<p>This topic provides migration and exploitation considerations for
zEnterprise server functions.</p>
<p>The following zEnterprise functions are available on z/OS
V1R12 and later releases: 
</p>
<ul>
<li><strong>InfiniBand Coupling.</strong>  Each system can use, or not use,
InfiniBand coupling links independently of what other systems are
doing, and do so in conjunction with other link types. InfiniBand
Coupling connectivity can only be performed with other systems that
also support InfiniBand Coupling.</li>
<li><strong>HiperDispatch.</strong>  The existing HIPERDISPATCH=YES|NO parameter
in IEAOPT<span class="synph"><span class="var">xx</span></span> member of parmlib, and on the
SET OPT=<span class="synph"><span class="var">xx</span></span> command to control whether HiperDispatch
is enabled or disabled for the system, can be changed dynamically.
  

<p>Beginning
with z/OS V1R13 when running on a zEnterprise server, the IEAOPT<span class="synph"><span class="var">xx</span></span> keyword
HIPERDISPATCH will default to YES. If HIPERDISPATCH=NO is specified,
the specification will be honored as it was on previous z/OS releases.
The IBM z/OS Health Checker check SUP_HiperDispatch checks whether
the expected HiperDispatch check parameter state (HIPERDISPATCH(YES)
or HIPERDISPATCH(NO), where YES is the default for the check, matches
the actual HiperDispatch state of the system. For more information,
see <a href="e0z3m100.htm#hyperz196">Accommodate HiperDispatch default of YES</a> .</p> 

<p>A WLM goal
adjustment might be required when using HiperDispatch. Review and
update your WLM policies as necessary.</p></li>
<li><strong>HiperDispatch cache and affinity node changes.</strong> This function
is enhanced to exploit zEnterprise architecture and now allows three
physical CPs from same chip to form affinity node. A z10 uses HiperDispatch book cache support and
four physical CPs from same book. 

<p>To realize the benefits of HiperDispatch,
z/OS has been changed to force HiperDispatch=YES for LPARs with greater
than 64 CPUs. On LPARs with greater than 64 CPUs defined on a zEnterprise
server with IEAOPT<span class="synph"><span class="var">xx</span></span> specifying HIPERDISPATCH=NO
during IPL (or SET OPT=<span class="synph"><span class="var">xx</span></span> after IPL), the
system generates a message but continues to run with HIPERDISPATCH=YES.
The new message is IRA865I HIPERDISPATCH=YES FORCED DUE TO GREATER
THAN 64 LPS DEFINED.</p> 

<p>On LPARs in which HIPERDISPATCH=NO is
specified with less than 64 CPUs, you can dynamically add more CPUs
and continue to run in HIPERDISPATCH=NO. However, you may see the
new message ISN012E HIPERDISPATCH MUST BE ENABLED TO CONFIGURE CPU
IDS GREATER THAN 3F ONLINE.</p> 

<p>Any attempt to configure CPUs greater
than 64 CPUs online in HIPERDISPATCH=NO will be rejected with message
IEE241I CPU(x) NOT RECONFIGURED ONLINE - REQUIRES HIPERDISPATCH ENABLED.</p> 

<p>An
LPAR with greater than 64 CPUs that dynamically changed to HIPERDISPATCH=YES
cannot go back to HIPERDISPATCH=NO.  It will be treated as if it was
IPLed with HIPERDISPATCH=YES after HIPERDISPATCH=YES is activated.</p> 

<p>To
assist with warning when you are getting close to 64 CPUs and running
with HIPERDISPATCH=NO, the IBM Health
Checker for z/OS check, SUP_HiperDispatchCPUConfig,
was added in z/OS V1R12. The check always succeeds for LPAR in HIPERDISPATCH=YES
(all CPU configurations supported). When an LPAR is running with HIPERDISPATCH=NO,
the check raises an exception when the number of CPUs is close to
forcing the LPAR to IPL with HIPERDISPATCH=YES. The CPUSLEFTB4NEEDHD
parameter indicates the minimum number of CPUs that can be installed
and activated on an LPAR running in HIPERDISPATCH=NO. When CPUSLEFTB4NEEDHD=0,
the check always succeeds. The default is 8, with values 0-63 accepted.
To assist with warning when you are getting close to 64 CPUs and running
with HIPERDISPATCH=NO, use IBM Health Checker for z/OS check, SUP_HiperDispatchCPUConfig.
Possible IBM Health Checker for z/OS messages:: 
</p>
<ul>
<li>IEAVEH080I CPU configuration supported with HiperDispatch <span class="synph"><span class="var">curstate</span></span></li>
<li>IEAVEH081E CPU configuration supported with HiperDispatch disabled. <span class="synph"><span class="var">numcpus</span></span> more
CPU(s) can be added with HiperDispatch disabled.</li></ul></li>
<li><strong>CFCC Level 17.</strong> If you are moving your coupling facilities
and the coupling facility structures will be on higher CFCC levels
than they were previously, run the Coupling Facility Structure Sizer
(CFSIZER) tool to find out if you have to increase coupling facility
structure sizes. zEnterprise servers initially shipped with CFCC Level
17. Prepare to make the necessary changes as indicated by the tool.
You can find the CFSIZER tool at <a href=" http://www.ibm.com/systems/support/z/cfsizer/">http://www.ibm.com/systems/support/z/cfsizer/</a>. 
<div>
<div class="note-noindent" id="wq117">
<span class="notetitle">Note:</span> <span class="notebody">The
PTFs to support CFCC Level 17 have coexistence (or sysplex preconditioning)
PTFs that require installation throughout your sysplex before implementing
CFCC Level 17.</span></div></div></li>
<li><strong>Third Subchannel Set.</strong> You now have the ability to extend
the amount of addressable storage capacity to help facilitate storage
growth with the introduction of a third subchannel set, an additional
64K devices, to help complement other functions such as "large" or
extended addressing volumes and HyperPAV. This may also help to facilitate
consistent device address definitions, simplifying addressing schemes
for congruous devices. 

<p>The first subchannel set (SS 0) allows definitions
of any type of device, such as bases, aliases, secondaries, and those
other than disk that do not implement the concept of associated aliases
or secondaries. The second and third subchannel sets (SS1 and SS2)
can now both be designated for use for disk alias devices (of both
primary and secondary devices), or Metro Mirror secondary devices
only. The third subchannel set applies ESCON, FICON and zHPF protocols. Definitions
for the third subchannel set are similar to those for the second subchannel
set and can be made with HCD.</p> 

<p>The
IODF statement of LOAD<span class="synph"><span class="var">xx</span></span> allows users to
indicate which devices to use during IPL (that is, devices that are
connected to subchannel set 0, 1 or 2). This specification is done
on the IODF statement (column 36).  For more information, see <cite>z/OS MVS Initialization and Tuning Reference</cite>.</p></li>
<li><strong>IPL from alternate subchannel set.</strong> This function allows
you to IPL from subchannel set 1 (SS1) or subchannel set 2 (SS2),
in addition to subchannel set 0. Devices used early during IPL processing
can now be accessed using subchannel set 1 or subchannel set 2. This
is intended to allow users of Metro Mirror (PPRC) secondary devices
defined using the same device number and a new device type in an alternate
subchannel set to be used for IPL, IODF, and standalone dump volumes
when needed. <span>IPL from an alternate subchannel set is
supported by z/OS V1R13 and V2R1, as well as z/OS V1R12 with PTFs,
and applies to the FICON and zHPF protocols (CHPID type FC). </span> 

<p>To IPL from an alternate subchannel set, you need to specify
a 5 digit load address on the LPAR image profile on the HMC, and have
the appropriate specification on the IODF statement column 36 in LOAD<span class="synph"><span class="var">xx</span></span>.
This capability is available only in z196 GA2 and z114. z114 supports
only SS0 and SS1, so you cannot IPL from subchannel set 2 (SS2).</p> 

<p><strong>Tip</strong>: Column 36 of the IODF statement in LOADxx is
the subchannel set indicator. This field indicates which subchannel
set should be used as the primary volume during IPL. You can now specify
an asterisk "*" for this value in the field to indicate that the subchannel
set of the IPL volume should be used as the subchannel set for the
primary volumes. APAR OA35135 for z/OS V1R11 and V1R12 added this
new function to specify a asterisk "*" in column 36 of the IODF statement
in LOADxx parmlib member.</p></li>
<li> <strong>IBM zEnterprise Unified
Resource Manager for enabling management and virtualization of heterogeneous
workloads.</strong> The Unified Resource Manager manages the deployment
of heterogeneous hardware resources based on individual workload requirements: 

<ul>
<li>Performance management</li>
<li>Integrated private data network</li></ul>  See <em>System z Ensemble
Planning and Configuration Guide</em> (GC27-2608)  for a detailed description
on the steps required.</li>
<li><strong>Power save mode. </strong> This function is available only
on z196 servers. There is a new SMFPRM<span class="synph"><span class="var">xx</span></span> parmlib
option, MAXEVENTINTRECS, that allows governing the number of event
interval records to be collected when the processor capacity changes.
The default is zero. This function is available only on z196 servers;
it is not available on z114 servers. 

<p>If you are using the CPU Measurement
Facility (Hardware Instrumentation Services), there is a new parameter
on the MODIFY <span class="synph"><span class="var">hisproc</span></span> command. You can use
this parameter, STATECHANGE, to override the default action to take
when a CPU speed change is detected within the HIS component.</p></li>
<li><strong>zHPF performance improvements for FICON Express8S.</strong> FICON
Express8S contains a new IBM ASIC which is designed to support the
8 Gbps (gigabytes per second) PCIe interface to the PCIe I/O drawer
and increased start I/Os. In addition, a hardware data router has
been added in support of the zHPF and FCP protocols for path length
reduction and increased throughput. FICON Express8S supports a link
data rate of 2, 4, or 8 Gbps autonegotiated. With these changes FICON
Express8S, when supporting the zHPF or FCP protocols, has been designed
to achieve full duplex line speed (8 Gbps) in each direction. The
performance of the FICON protocol remains unchanged from FICON Express8.
To use zHPF performance improvements for FICON Express8S, you need
to specify the <span class="synph"><span class="kwd">ZHPF=YES | NO</span></span> parameter in
the IECIOS<span class="synph"><span class="var">xx</span></span> of PARMLIB and use FICON Express8S.</li>
<li><strong>Additional Crypto exploitation.</strong> The following enhancements
have been added to the Common Cryptographic Architecture support,
which is used in the Crypto Express3 feature when it is configured
as a coprocessor:  

<ul>
<li>ANSI X9.8 Pin security</li>
<li>Enhanced Common Cryptographic Architecture (CCA), 64bit, CP Assist
for Cryptographic Function (CPACF) enhancements</li>
<li>Secure Keyed-Hash Message Authentication Code (HMAC)</li>
<li>CKDS Constraint Relief</li>
<li>PCI Audit, Elliptical Curve Cryptography (ECC) Digital Signature
Algorithm</li>
<li>CBC Key Wrap</li>
<li>PKA RSA OEAP with SHA-256</li>
<li>Expanded support for AES algorithm</li>
<li>Enhanced ANSI TR-31 Secure Key Exchange</li>
<li>PIN block decimalization table protection</li>
<li>PKA RSA OAEP with SHA-256 algorithm, additional Elliptic Curve
Cryptography (ECC) functions.</li></ul></li>
<li><strong>z/OS Discovery and AutoConfiguration (zDAC) for FICON channels.</strong> With a zEnterprise
CPC and z/OS, a new function, z/OS Discovery and AutoConfiguration
(zDAC), is designed to automatically perform a number of I/O configuration
definition tasks for new and changed disk and tape controllers through
FICON channels. Starting with z/OS V2R1 FICON point-to-point paths
are also included in the discovery process whether or not they are
connected to a switch or director when attached to a FICON channel. When new controllers are added
to an I/O configuration, or changes are made to existing controllers,
the system is designed to discover them and propose configuration
changes based on a policy you define in the hardware configuration
dialog (HCD). Your policy can include preferences for availability
and bandwidth including parallel access volume (PAV) definitions,
control unit numbers, and device number ranges. 

<p>zDAC is designed
to perform discovery for all systems in a sysplex that support the
function. The proposed configuration will incorporate the current
contents of the I/O definition file (IODF) with additions for newly
installed and changed control units and devices. zDAC is designed
to help simplify I/O configuration on CPC running z/OS and reduce complexity and setup time. zDAC
applies to all FICON features
supported on zEnterprise servers when configured as CHPID type FC,
and is supported by z/OS V1R12 and later.</p> 

<p>To use zDAC, you
must first establish a policy for the discovery operation. This is
done through HCD or HCM. You can limit the scope of the discovery,
limit the proposal information, indicate the desired number of paths
to discovered logical control units, and indicate the method used
for device and control unit numbering. After controllers and devices
are discovered, you can select which controllers to be defined and
accept or override the proposed values for control units and devices.</p></li>
<li><strong>OSA-Express3 and OSA-Express4S Inbound Workload Queuing (IWQ).</strong> 
Inbound workload queuing for Enterprise Extender is supported by the
OSA-Express4S and OSA-Express3 features when defined as CHPID types
OSD or OSX. It is exclusive to the z196 and z114 servers, and is supported
by z/OS and by z/VM for guest exploitation. OSA-Express3 introduces
inbound workload queuing (IWQ), which creates multiple input queues
and allows OSA to differentiate workloads "off the wire" and then
assign work to a specific input queue (per device) to z/OS. With each
input queue representing a unique type of workload, each having unique
service and processing requirements, the IWQ function allows z/OS to preassign the appropriate
processing resources for each input queue. This approach allows multiple
concurrent z/OS processing
threads to then process each unique input queue (workload), avoiding
traditional resource contention. In a heavily mixed workload environment,
this "off the wire" network traffic separation provided by OSA-Express3
IWQ reduces the conventional z/OS processing required to identify
and separate unique workloads, which results in improved overall system
performance and scalability. The types of z/OS workloads that are
identified and assigned to unique input queues are: 

<ul>
<li>z/OS Sysplex Distributor traffic: Network traffic that is associated
with a distributed Virtual Internet Protocol Address (VIPA) is assigned
a unique input queue allowing the Sysplex Distributor traffic to be
immediately distributed to the target host.</li>
<li>z/OS bulk data traffic: Network traffic that is dynamically associated
with a streaming (bulk data) TCP connection is assigned to a unique
input queue allowing the bulk data processing to be assigned the appropriate
resources and isolated from critical interactive workloads.</li></ul> 

<p>IWQ is supported on zEnterprise CPC and System z10, and is exclusive to OSA-Express3 CHPID types
OSD and OSX (exclusive to zEnterprise CPC). There are some Communications
Server configuration settings required to enable multiple inbound
data queues.</p></li>
<li><strong>Display OSAINFO.</strong> OSA-Express3 introduces the capability
for the operating system to directly query and display the current
OSA configuration information (similar to OSA/SF). z/OS exploits this new OSA capability by introducing
a new TCP/IP operator command, Display OSAINFO. Display OSAINFO allows
the operator to monitor and verify the current OSA configuration,
which helps to improve the overall management, serviceability, and
usability of OSA-Express3. The Display OSAINFO command is exclusive
to OSA-Express3 CHPID types OSD, OSM, and OSX (on z196, z114, and z10 servers).</li>
<li><strong>C/C++ ARCH(9) and TUNE(9) options.</strong> The ARCHITECTURE C/C++
compiler option selects the minimum level of machine architecture
on which your program can run. Certain features provided by the compiler
require a minimum architecture level. ARCH(9) exploits instructions
available on zEnterprise servers. For more information, refer to the
ARCHITECTURE compiler option in <cite>z/OS XL C/C++ User's Guide</cite>.
The TUNE compiler option allows you to optimize your application for
specific machine architecture. The TUNE level has to be at the ARCH
level, at a minimum. If the TUNE level is lower than the specified
ARCH level, the compiler forces TUNE to match the ARCH level, or uses
the default TUNE level, whichever is greater. For more information
about the ARCHITECTURE and TUNE compiler options refer to <cite>z/OS XL C/C++ User's Guide</cite>. 

<p><strong>Exploitation
restriction.</strong> When programs exploit the ARCH(9) or TUNE(9) option,
those programs can only run on zEnterprise servers, or an operation
exception will occur. This is a consideration for programs that will
run on different server levels (z10 and z9 servers) during development, test,
and production, as well as during fallback or disaster recovery.</p></li></ul>
<p>The following zEnterprise functions are only available on z/OS
V1R13 and later releases. See <cite>z/OS Introduction and Release Guide</cite> 
for restrictions, dependencies, and steps to take to use these new
hardware functions): 
</p>
<ul>
<li><strong>OSA-Express4S checksum offload for LPAR-to-LPAR traffic for
IPv4 and IPv6 packets (CHPID type OSD).</strong> Checksum offload for LPAR-to-LPAR
traffic is included in the OSA-Express4S design. The checksum function
has been moved from the PCIe adapter to the OSA-Express4S hardware
to help reduce CPU utilization.</li>
<li><strong> OSA-Express4S large send for IPv6 packets (CHPID types OSD
and OSX).</strong> Large send (also referred to as TCP segmentation offload)
is designed to improve performance by offloading outbound TCP segmentation
processing from the host to an OSA-Express4S feature by employing
a more efficient memory transfer into OSA-Express4. Large send support
for IPv6 packets applies to the OSA-Express4S features (CHPID type
OSD and OSX), and is exclusive to z196 and z114.</li>
<li><strong>Inbound workload queuing for Enterprise Extender.</strong> Inbound
workload queuing (IWQ) for the OSA-Express4S features has been enhanced
to differentiate and separate inbound Enterprise Extender traffic
to a new input queue. The Enterprise Extender separation and processing
associated with the Enterprise Extender input queue provides improved
scalability and performance for Enterprise Extender.</li></ul><p class="indatacontent"> </p>
<div>
<div class="note-noindent" id="wq118">
<span class="notetitle">Note:</span> <span class="notebody">  See <cite>z/OS Communications Server: IP Configuration Guide</cite> for
additional information about OSA-Express4S checksum offload for LPAR-to-LPAR
traffic for IPv4 and IPv6 packets (CHPID type OSD), OSA-Express4S
large send for IPv6 packets (CHPID types OSD and OSX), and Inbound
workload queuing for Enterprise Extender.</span></div></div>
<h4 id="znxtrmss2">Recommended migration steps for z196 and z114 servers</h4>
<p>This topic suggests the steps for migrating your same z/OS release level from your current server
to a zEnterprise server.
The steps are based on the assumption that you want to minimize the
amount of change (and therefore risk) and the amount of work required
to perform the migration.</p>
<p>Your migration steps follow:</p>
<ol type="1">
<li>If necessary, migrate to an STP-only or Mixed-CTN timing network.</li>
<li>Ensure that you have installed the z196, z114, z10 EC (or z10 BC), and z9 EC
(or z9 BC) required service,
as indicated in the respective PSP buckets. See <strong>Install the necessary z/OS service, as indicated in PSP
buckets</strong> in <a href="e0z3m100.htm#znextbef">Actions you can take before you order a z196 and z114 server</a>  before
you order a z196 and z114 server for information about how to identify,
acquire, and install any missing required service.</li>
<li>Ensure you have the required service, and any required ICSF web
deliverable installed for the cryptographic functions that you have
decided to use.</li>
<li>Upgrade your hardware to zEnterprise system.
If necessary convert to InfiniBand Coupling Links from ICB-4 links.</li>
<li>Update configuration setting to exploit zEnterprise functions.</li></ol>
<h4 id="znextexp2">Migration and exploitation considerations for z196 and z114
server functions</h4>
<p>This topic provides migration and exploitation considerations for zEnterprise server functions.</p>
<p>The following zEnterprise functions
are available on z/OS V1R12
and later releases: 
</p>
<ul>
<li><strong>InfiniBand Coupling.</strong>  Each system can use, or not use,
InfiniBand coupling links independently of what other systems are
doing, and do so in conjunction with other link types. InfiniBand
Coupling connectivity can only be performed with other systems that
also support InfiniBand Coupling.</li>
<li><strong>HiperDispatch.</strong>  The existing HIPERDISPATCH=YES|NO parameter
in IEAOPT<span class="synph"><span class="var">xx</span></span> member of parmlib, and on the
SET OPT=<span class="synph"><span class="var">xx</span></span> command to control whether HiperDispatch
is enabled or disabled for the system, can be changed dynamically.
 The default is that HiperDispatch is disabled on z/OS V1R7 through z/OS V1R12.  

<p>Beginning
with z/OS V1R13 when running
on a zEnterprise server,
the IEAOPT<span class="synph"><span class="var">xx</span></span> keyword HIPERDISPATCH will
default to YES. If HIPERDISPATCH=NO is specified, the specification
will be honored as it was on previous z/OS releases.
The IBM z/OS Health Checker check SUP_HiperDispatch
checks whether the expected HiperDispatch check parameter state (HIPERDISPATCH(YES)
or HIPERDISPATCH(NO), where YES is the default for the check, matches
the actual HiperDispatch state of the system. For more information,
see <a href="e0z3m100.htm#hyperz196">Accommodate HiperDispatch default of YES</a> .</p> 

<p>A WLM goal
adjustment might be required when using HiperDispatch. Review and
update your WLM policies as necessary.</p></li>
<li><strong>HiperDispatch cache and affinity node changes.</strong> This function
is enhanced to exploit zEnterprise architecture
and now allows three physical CPs from same chip to form affinity
node. A z10 uses HiperDispatch
book cache support and four physical CPs from same book. 

<p>To realize
the benefits of HiperDispatch, z/OS has
been changed to force HiperDispatch=YES for LPARs with greater than
64 CPUs. On LPARs with greater than 64 CPUs defined on a zEnterprise server with IEAOPT<span class="synph"><span class="var">xx</span></span> specifying
HIPERDISPATCH=NO during IPL (or SET OPT=<span class="synph"><span class="var">xx</span></span> after
IPL), the system generates a message but continues to run with HIPERDISPATCH=YES.
The new message is IRA865I HIPERDISPATCH=YES FORCED DUE TO GREATER
THAN 64 LPS DEFINED.</p> 

<p>On LPARs in which HIPERDISPATCH=NO is
specified with less than 64 CPUs, you can dynamically add more CPUs
and continue to run in HIPERDISPATCH=NO. However, you may see the
new message ISN012E HIPERDISPATCH MUST BE ENABLED TO CONFIGURE CPU
IDS GREATER THAN 3F ONLINE.</p> 

<p>Any attempt to configure CPUs greater
than 64 CPUs online in HIPERDISPATCH=NO will be rejected with message
IEE241I CPU(x) NOT RECONFIGURED ONLINE - REQUIRES HIPERDISPATCH ENABLED.</p> 

<p>An
LPAR with greater than 64 CPUs that dynamically changed to HIPERDISPATCH=YES
cannot go back to HIPERDISPATCH=NO.  It will be treated as if it was
IPLed with HIPERDISPATCH=YES after HIPERDISPATCH=YES is activated.</p> 

<p>To
assist with warning when you are getting close to 64 CPUs and running
with HIPERDISPATCH=NO, the IBM Health
Checker for z/OS check, SUP_HiperDispatchCPUConfig,
was added in z/OS V1R12 and
available on z/OS V1R11 with
APAR OA30476. The check always succeeds for LPAR in HIPERDISPATCH=YES
(all CPU configurations supported). When an LPAR is running with HIPERDISPATCH=NO,
the check raises an exception when the number of CPUs is close to
forcing the LPAR to IPL with HIPERDISPATCH=YES. The CPUSLEFTB4NEEDHD
parameter indicates the minimum number of CPUs that can be installed
and activated on an LPAR running in HIPERDISPATCH=NO. When CPUSLEFTB4NEEDHD=0,
the check always succeeds. The default is 8, with values 0-63 accepted.
The system redrives the check when the HIPERDISPATCH state changes
or CPUs are dynamically added. Possible IBM Health
Checker for z/OS messages: 
</p>
<ul>
<li>IEAVEH080I CPU configuration supported with HiperDispatch <span class="synph"><span class="var">curstate</span></span></li>
<li>IEAVEH081E CPU configuration supported with HiperDispatch disabled. <span class="synph"><span class="var">numcpus</span></span> more
CPU(s) can be added with HiperDispatch disabled.</li></ul></li>
<li><strong>CFCC Level 17.</strong> If you are moving your coupling
facilities and the coupling facility structures will be on higher
CFCC levels than they were previously, run the Coupling Facility Structure
Sizer (CFSIZER) tool to find out if you have to increase coupling
facility structure sizes. Run the Sizer utility, an authorized z/OS
program that you can download, to evaluate structure size changes. zEnterprise servers initially
shipped with CFCC Level 17. Prepare to make the necessary changes
as indicated by the tool. You can find the CFSIZER tool at <a href=" http://www.ibm.com/systems/support/z/cfsizer/">http://www.ibm.com/systems/support/z/cfsizer/</a>. 
<div>
<div class="note-noindent" id="wq120">
<span class="notetitle">Note:</span> <span class="notebody">The
PTFs to support CFCC Level 17 have coexistence (or sysplex preconditioning)
PTFs that require installation throughout your sysplex prior to implementing
CFCC Level 17.</span></div></div></li>
<li><strong>Third Subchannel Set.</strong> You now have the ability to extend
the amount of addressable storage capacity to help facilitate storage
growth with the introduction of a third subchannel set, an additional
64K devices, to help complement other functions such as "large" or
extended addressing volumes and HyperPAV. This may also help to facilitate
consistent device address definitions, simplifying addressing schemes
for congruous devices. 

<p>The first subchannel set (SS 0) allows definitions
of any type of device, such as bases, aliases, secondaries, and those
other than disk that do not implement the concept of associated aliases
or secondaries. The second and third subchannel sets (SS1 and SS2)
can now both be designated for use for disk alias devices (of both
primary and secondary devices), or Metro Mirror secondary devices
only. The third subchannel set applies ESCON, FICON and zHPF protocols. Definitions
for the third subchannel set are similar to those for the second subchannel
set and can be made with HCD.</p> 

<p>The
IODF statement of LOAD<span class="synph"><span class="var">xx</span></span> allows users to
indicate which devices to use during IPL (that is, devices that are
connected to subchannel set 0, 1 or 2). This specification is done
on the IODF statement (column 36).  For more information, see <cite>z/OS MVS Initialization and Tuning Reference</cite>.</p></li>
<li><strong>IPL from alternate subchannel set.</strong> This function allows
you to IPL from subchannel set 1 (SS1) or subchannel set 2 (SS2),
in addition to subchannel set 0. Devices used early during IPL processing
can now be accessed using subchannel set 1 or subchannel set 2. This
is intended to allow users of Metro Mirror (PPRC) secondary devices
defined using the same device number and a new device type in an alternate
subchannel set to be used for IPL, IODF, and standalone dump volumes
when needed. IPL from an alternate subchannel set is supported
by z/OS V1R13, as well as z/OS V1R12 and z/OS V1R11 with PTFs, and applies to the FICON and zHPF protocols (CHPID
type FC). 

<p>To IPL from an alternate subchannel set,
you need to specify a 5 digit load address on the LPAR image profile
on the HMC, and have the appropriate specification on the IODF statement
(column 36) in LOAD<span class="synph"><span class="var">xx</span></span>. z114 supports only
SS0 and SS1, so performing an IPL from subchannel set 2 (SS2) is not
possible.</p>

<p><strong>Tip</strong>: Column 36 of the IODF statement
in LOADxx is the subchannel set indicator. This field indicates which
subchannel set should be used as the primary volume during IPL. You
can now specify an asterisk "*" for this value in the field to indicate
that the subchannel set of the IPL volume should be used as the subchannel
set for the primary volumes. APAR OA35135 for z/OS V1R11 and V1R12
added the new function to specify an asterisk "*" in column 36 of
the IODF statement in LOADxx parmlib member.</p></li>
<li> <strong>IBM zEnterprise Unified Resource Manager
for enabling management and virtualization of heterogeneous workloads.</strong> The
Unified Resource Manager manages the deployment of heterogeneous hardware
resources based on individual workload requirements: 

<ul>
<li>Performance management</li>
<li>Integrated private data network</li></ul>  See <em>System z Ensemble
Planning and Configuration Guide</em> (GC27-2608)  for a detailed description
on the steps required.</li>
<li><strong>Power save
mode. </strong> This function is available only on z196 servers; it is
not available on z114 servers. There is a new SMFPRM<span class="synph"><span class="var">xx</span></span> parmlib
option, MAXEVENTINTRECS, that allows governing the number of event
interval records to be collected when the processor capacity changes.
The default is zero. To collect extra records between regular intervals
when the processor capacity changes, the default must be adjusted. 

<p>If
you are using the CPU Measurement Facility (Hardware Instrumentation
Services), there is a new parameter on the MODIFY <span class="synph"><span class="var">hisproc</span></span> command.
You can use this parameter, STATECHANGE, to override the default action
to take when a CPU speed change is detected within the HIS component.</p></li>
<li><strong>zHPF performance improvements for FICON Express8S.</strong> FICON Express8S contains a new IBM ASIC which is designed to support the 8 Gbps
(gigabytes per second) PCIe interface to the PCIe I/O drawer and increased
start I/Os. In addition, a hardware data router has been added in
support of the zHPF and FCP protocols for path length reduction and
increased throughput. FICON Express8S
supports a link data rate of 2, 4, or 8 Gbps autonegotiated. With
these changes FICON Express8S,
when supporting the zHPF or FCP protocols, has been designed to achieve
full duplex line speed (8 Gbps) in each direction. The performance
of the FICON protocol remains
unchanged from FICON Express8.
To use zHPF performance improvements for FICON Express8S, you need to specify the <span class="synph"><span class="kwd">ZHPF=YES
| NO</span></span> parameter in the IECIOS<span class="synph"><span class="var">xx</span></span> of
PARMLIB and use FICON Express8S</li>
<li><strong>Additional Crypto exploitation.</strong> The following enhancements
have been added to the Common Cryptographic Architecture support,
which is used in the Crypto Express3 feature when it is configured
as a coprocessor:  

<ul>
<li>ANSI X9.8 Pin security</li>
<li>Enhanced Common Cryptographic Architecture (CCA), 64bit, CP Assist
for Cryptographic Function (CPACF) enhancements</li>
<li>Secure Keyed-Hash Message Authentication Code (HMAC)</li>
<li>CKDS Constraint Relief</li>
<li>PCI Audit, Elliptical Curve Cryptography (ECC) Digital Signature
Algorithm</li>
<li>CBC Key Wrap</li>
<li>PKA RSA OEAP with SHA-256</li>
<li>Expanded support for AES algorithm</li>
<li>Enhanced ANSI TR-31 Secure Key Exchange</li>
<li>PIN block decimalization table protection</li>
<li>PKA RSA OAEP with SHA-256 algorithm, additional Elliptic Curve
Cryptography (ECC) functions.</li></ul></li></ul>
<p>The following zEnterprise functions
are only available on z/OS V1R12
and later releases: 
</p>
<ul>
<li><strong>z/OS Discovery
and AutoConfiguration (zDAC) for FICON channels.</strong> With
a zEnterprise CPC and z/OS, a new function, z/OS Discovery and AutoConfiguration (zDAC),
is designed to automatically perform a number of I/O configuration
definition tasks for new and changed disk and tape controllers through
FICON channels. FICON point-to-point paths are also included in the
discovery process.  When new controllers are added to an I/O configuration,
or changes are made to existing controllers, the system is designed
to discover them and propose configuration changes based on a policy
you define in the hardware configuration dialog (HCD). Your policy
can include preferences for availability and bandwidth including parallel
access volume (PAV) definitions, control unit numbers, and device
number ranges. 

<p>zDAC is designed to perform discovery for all systems
in a sysplex that support the function. The proposed configuration
will incorporate the current contents of the I/O definition file (IODF)
with additions for newly installed and changed control units and devices.
zDAC is designed to help simplify I/O configuration on CPC running z/OS and reduce complexity and
setup time. zDAC applies to all FICON features
supported on zEnterprise servers
when configured as CHPID type FC, and is supported by z/OS V1R12 and later.</p> 

<p>To use zDAC, you
must first establish a policy for the discovery operation. This is
done through HCD or HCM. You can limit the scope of the discovery,
limit the proposal information, indicate the desired number of paths
to discovered logical control units, and indicate the method used
for device and control unit numbering. After controllers and devices
are discovered, you can select which controllers to be defined and
accept or override the proposed values for control units and devices.</p></li>
<li><strong>OSA-Express3 and OSA-Express4S Inbound Workload Queuing (IWQ).</strong> 
Inbound workload queuing for Enterprise Extender is supported by the
OSA-Express4S and OSA-Express3 features when defined as CHPID types
OSD or OSX. It is exclusive to the z196 and z114 servers, and is supported
by z/OS and by z/VM&reg; for guest exploitation. OSA-Express3 introduces
inbound workload queuing (IWQ), which creates multiple input queues
and allows OSA to differentiate workloads "off the wire" and then
assign work to a specific input queue (per device) to z/OS. With each input queue representing a unique
type of workload, each having unique service and processing requirements,
the IWQ function allows z/OS to
preassign the appropriate processing resources for each input queue.
This approach allows multiple concurrent z/OS processing threads to then process each
unique input queue (workload), avoiding traditional resource contention.
In a heavily mixed workload environment, this "off the wire" network
traffic separation provided by OSA-Express3 IWQ reduces the conventional z/OS processing required to identify
and separate unique workloads, which results in improved overall system
performance and scalability. The types of z/OS workloads that are identified and assigned
to unique input queues are: 

<ul>
<li>z/OS Sysplex Distributor
traffic: Network traffic that is associated with a distributed Virtual
Internet Protocol Address (VIPA) is assigned a unique input queue
allowing the Sysplex Distributor traffic to be immediately distributed
to the target host.</li>
<li>z/OS bulk data traffic:
Network traffic that is dynamically associated with a streaming (bulk
data) TCP connection is assigned to a unique input queue allowing
the bulk data processing to be assigned the appropriate resources
and isolated from critical interactive workloads.</li></ul> 

<p>IWQ is supported on zEnterprise CPC
and System z10, and is exclusive
to OSA-Express3 CHPID types OSD and OSX (exclusive to zEnterprise CPC). There are some Communications
Server configuration settings required to enable multiple inbound
data queues.</p></li>
<li><strong>Display OSAINFO.</strong> OSA-Express3 introduces the capability
for the operating system to directly query and display the current
OSA configuration information (similar to OSA/SF). z/OS exploits this new OSA capability by introducing
a new TCP/IP operator command, Display OSAINFO. Display OSAINFO allows
the operator to monitor and verify the current OSA configuration,
which helps to improve the overall management, serviceability, and
usability of OSA-Express3. The Display OSAINFO command is exclusive
to OSA-Express3 CHPID types OSD, OSM, and OSX (on z196, z114, and z10 servers).</li>
<li><strong>C/C++ ARCH(9) and TUNE(9) options.</strong> The ARCHITECTURE XL
C/C++ compiler option selects the minimum level of machine architecture
on which your program can run. Certain features provided by the compiler
require a minimum architecture level. ARCH(9) exploits instructions
available on zEnterprise servers.
The TUNE compiler option allows you to optimize your application for
specific machine architecture. The TUNE level has to be at the ARCH
level, at a minimum. If the TUNE level is lower than the specified
ARCH level, the compiler forces TUNE to match the ARCH level, or uses
the default TUNE level, whichever is greater. For more information
about the ARCHITECTURE XL and TUNE compiler options, see <cite>z/OS XL C/C++ User's Guide</cite>.
 

<p><strong>Exploitation restriction.</strong> When programs exploit the ARCH(9)
or TUNE(9) option, those programs can only run on zEnterprise servers, or an operation
exception will occur. This is a consideration for programs that will
run on different server levels (z10 and z9 servers) during development, test,
and production, as well as during fallback or disaster recovery.</p> 

<p>For
example, the XL C/C++ ARCH(10) and TUNE(10) option exploits instructions
available only on a zEC12 server. When programs exploit the ARCH(10)
or TUNE(10) option, those programs can only run on a zEC12 server,
or an operation exception will occur.</p></li></ul>
<p>The following zEnterprise functions
are only available on z/OS V1R13
and later releases. See <cite>z/OS Introduction and Release Guide</cite> 
for restrictions, dependencies, and steps to take to use these new
hardware functions): 
</p>
<ul>
<li><strong>OSA-Express4S checksum offload for LPAR-to-LPAR traffic for
IPv4 and IPv6 packets (CHPID type OSD).</strong> Checksum offload for LPAR-to-LPAR
traffic is included in the OSA-Express4S design. The checksum function
has been moved from the PCIe adapter to the OSA-Express4S hardware
to help reduce CPU utilization.</li>
<li><strong> OSA-Express4S large send for IPv6 packets (CHPID types OSD
and OSX).</strong> Large send (also referred to as TCP segmentation offload)
is designed to improve performance by offloading outbound TCP segmentation
processing from the host to an OSA-Express4S feature by employing
a more efficient memory transfer into OSA-Express4. Large send support
for IPv6 packets applies to the OSA-Express4S features (CHPID type
OSD and OSX), and is exclusive to zEC12, z196, and z114.</li>
<li><strong>Inbound workload queuing for Enterprise Extender.</strong> Inbound
workload queuing (IWQ) for the OSA-Express4S features has been enhanced
to differentiate and separate inbound Enterprise Extender traffic
to a new input queue. The Enterprise Extender separation and processing
associated with the Enterprise Extender input queue provides improved
scalability and performance for Enterprise Extender.</li></ul><p class="indatacontent"> </p>
<div>
<div class="note-noindent" id="wq121">
<span class="notetitle">Note:</span> <span class="notebody">  See <cite>z/OS Communications Server: IP Configuration Guide</cite> for
additional information about OSA-Express4S checksum offload for LPAR-to-LPAR
traffic for IPv4 and IPv6 packets (CHPID type OSD), OSA-Express4S
large send for IPv6 packets (CHPID types OSD and OSX), and Inbound
workload queuing for Enterprise Extender.</span></div></div>
<h3 id="migrz10">Migrate to a System z10 server</h3>
<p><strong>Description</strong>: The IBM System z10 servers
(z10 EC and z10 BC) are follow ons to the IBM System z9 servers
(z9 EC [formerly z9-109] and z9 BC) and IBM eServer zSeries servers (z990, z890,
z900, and z800). The System z10 servers
build on the inherent strengths of the System z platform, deliver new technologies that
offer dramatic improvements in price and performance for key new workloads,
and enable a new range of hybrid solutions.</p>
<p><a id="idx197"></a><a id="idx198"></a><a id="idx199"></a><a id="idx200"></a><a id="idx201"></a><a id="idx202"></a><a id="idx203"></a><a id="idx204"></a>The specific System z10 functions exploited by z/OS V2R1,
z/OS V1R13, and V1R12 as part of the base z/OS support  are:

</p>
<ul>
<li>Dynamic addition of logical CPs without preplanning</li>
<li>RMF FICON enhancement</li>
<li>Greater than 54 CPs (64) for a single LPAR (z10 EC only)</li>
<li>XL C/C++ ARCH(8) and TUNE(8)</li>
<li>Large memory (up to 1 TB on z10 EC
now, up to 248 GB on z10 BC planned
for 30Jun2009)</li>
<li>HiperDispatch</li>
<li>CPACF and Configurable Crypto Express2</li>
<li>Key management for remote loading of ATM and point-of-sale
(POS) keys and support for ISO 16609 CBC Mode T-DES MAC requirements</li>
<li>New z/Architecture instructions</li>
<li>65535 MP factors</li>
<li>OSA-Express3 10 Gigabit Ethernet</li>
<li>FICON8 enhancement</li>
<li>OSA-Express3 Gigabit Ethernet</li>
<li>1000BASE-T Ethernet</li>
<li>Protected Key CP Assist for Cryptographic Function</li>
<li>New Crypto Express3 and Crypto Express3 -1P</li></ul>
<p>The specific System z10 functions exploited by z/OS V2R1,
z/OS V1R13, and V1R12 as part of the explicit z/OS support  are:

</p>
<ul>
<li>HiperSockets Multiple
Write Facility</li>
<li>Capacity Provisioning</li>
<li>Large page support</li>
<li>OSA-Express3 double port density</li>
<li>CPU Measurement Facility architecture</li>
<li>Service aids support for large dumps</li>
<li>Layer 3 VMAC support (VMAC Support for OSA-Express2 and OSA-Express3
when configured as CHPID type OSD [QDIO])</li>
<li>CPACF enhanced to support SHA-384 and SHA-512 bit for message
digest, ISO Format 3 PIN blocks, secure key AES, support for RSA keys
up to 4096 bits in length, dynamically add crypto to a logical partition,
Random Number Generator Long, and enhanced TKE auditin</li>
<li>Support for 13-digit through 19-digit PAN data, ICSF Query service,
and enhanced SAF checking</li>
<li>Coupling facility level 16</li>
<li>High Performance FICON for System z (zHPF)</li>
<li>Decimal floating point</li>
<li>Usage Report Program (IFAURP) support</li>
<li>Parallel Sysplex InfiniBand
(PSIFB) coupling links</li></ul>
<table id="wq122" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>The System z10 EC
server, which first shipped in February 2008.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V2R1, z/OS V1R13, and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Anytime.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to run z/OS on a System z10 server.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>A System z10 server.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>See the appropriate PSP buckets for required
web deliverables and PTFs for specific functions, as described in <a href="e0z3m100.htm#z10rmss">Recommended migration steps for a System z10 server</a>.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>See the appropriate PSP buckets for required
PTFs for specific functions, as described in <a href="e0z3m100.htm#z10rmss">Recommended migration steps for a System z10 server</a>.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Follow the recommendations
and considerations, adhere to the restrictions, and perform the tasks
described in the topics below.</p>
<h4 id="e0z3m100-gen9">General recommendations and considerations for a System z10
server</h4>
<p>As you plan your migration to a System z10 server,
consider the following:</p>
<ol type="1">
<li><strong>Relatively few migration actions are new when coming from a
System z9 server.</strong> Migration
to a System z10 server has, as
its basis, a migration to a z9 EC
or z9 BC. This means that if
you are migrating to a System z10 server
from a z9 EC or z9 BC (and have performed the migration actions
associated with the z9 EC or z9 BC), you have fewer migration
actions than if you were migrating from a server before the z9 EC or z9 BC
and have not yet performed the migration actions associated with the z9 EC or z9 BC.
There are, in fact, very few new migration actions to perform on z/OS for a System z10 server if you have already migrated to a z9 EC or z9 BC.
It is important to note that you can migrate directly to a System z10 server without installing the
intermediate (before z9 EC and z9 BC) servers, but you still need
to ensure that any migration considerations are satisfied for the
servers that you &quot;skipped&quot;.</li>
<li><strong>Support is delivered by service (and FMID web deliverables
for ICSF).</strong> The delta (from a z9 EC
or z9 BC) support for a System z10 server, excluding cryptographic
support, is delivered by service (PTFs).  Some cryptographic support
for the System z10 (and earlier)
servers is provided by a web deliverable (FMID). Depending on the
cryptographic support provided and the z/OS release
that you are running, you might need to download and install a different
ICSF web deliverable.</li>
<li><strong>Larger coupling facility structure sizes might be necessary.</strong> When
you change coupling facility control code (CFCC) levels, your coupling
facility structure sizes might change. <span>System z10 servers initially shipped with
CFCC level 16</span>. If, as part of your migration to a System z10 server, you change CFCC levels
(either by placing a coupling facility on the System z10 server or by moving the coupling facility
to a z9 EC or z9 BC at a later CFCC level), you might have larger
structure sizes than you did previously. If your CFCC levels are identical,
structure sizes are not expected to change when you migrate from a
previous server to a System z10 server.</li>
<li><strong>Update CFRM policies.</strong> Coupling facilities are identified
in the CFRM policy by their physical node descriptor information (for
example, machine type, model, serial number, LPAR number). When a
coupling facility undergoes a hardware upgrade, one or more of these
pieces of information is likely to change, therefore, the definition
of the coupling facility in the CFRM policy must change accordingly.</li>
<li><strong>Use the same software level throughout a sysplex.</strong> Having
members of a sysplex at the same software level (other than during
brief migration periods) is good software management policy.</li>
<li><strong>Migrate hardware and software at different times.</strong> To minimize
the amount of change (and therefore risk) that you experience at one
time, do not migrate your software release level at the same time
that you migrate your hardware.</li></ol>
<h4 id="e0z3m100-gen10">Restrictions for a System z10 server</h4>
<p>Restrictions associated with the System z10 server are:</p>
<ol type="1">
<li><strong>Functional limitations</strong>: Not all System z10 functions are available in every z/OS release. See <a href="e0z3m100.htm#migrz10">Migrate to a System z10 server</a> for a list of the System z10 functions
available in each z/OS release. Some functions have exploitation or
migration considerations (see below).  Many functions are enabled
or disabled, based on the presence or absence of the required hardware
and software. If you wish to position to exploit any new System z10 functions, the software and hardware
may be installed in either order. That is, there is no requirement
to install either software or hardware first to exploit a specific
function.</li>
<li><strong>System z10 in
a sysplex</strong>: 


<ul>
<li>The z9 EC and z9 BC are the last servers to support active participation
in the same Parallel
Sysplex with z900, z800, and earlier servers.  If you are running z/OS on a z900 or z800, you cannot
add a System z10 server to that
sysplex. That is, you will not be able to perform rolling IPLs to
introduce a System z10 server
if you have any z900 or z800 images (either as z/OS images or coupling facilities) in the sysplex.
Any z900 or z800 servers in the sysplex have to be upgraded to a z990,
z890, or later server to have a System z10 server
supported in the sysplex.  If you have any z/OS images or coupling facilities on a z900 or
z800, and you intend to introduce a System z10 server into that sysplex, you must migrate those
images to z990 or z890 (or later) before introducing the System z10 server.</li>
<li>The Integrated Cluster Bus (ICB) connector on the System z10 server is different than on previous
servers, requiring new links and connectors to be installed on previous
servers in order to connect them to a System z10 server by ICB. This is a hardware-only migration
action.</li>
<li>The z10 EC model E64 servers
cannot use ICB-4 coupling links. On this model, all required coupling
link connectivity must be provided using PSIFB and/or ISC-3 coupling
links.</li></ul></li></ol>
<h4 id="e0z3m100-gen11">Actions you can take before you order a System z10 server</h4>
<p>You can perform the following migration actions before you order
or install your System z10 server:</p>
<ol type="1">
<li><strong>Review the sysplex configuration in which the System z10 server will participate.</strong> In
particular, if you have any existing z900 or z800 z/OS images or coupling facilities in the sysplex,
move these z/OS images or coupling facilities to later servers (such
as z990 or z890 or later). This action is necessitated by the restriction
that a System z10 server cannot
participate with a z900 or z800 in a sysplex.</li>
<li><strong>Install new links and connectors on earlier servers.</strong> This
action is necessitated because the ICB connector on the System z10 server is different than on previous
servers.</li>
<li><strong>Review restrictions and coexistence requirements for
earlier servers.</strong> Because the z9 EC
and z9 BC support is the basis
for the System z10 server support,
the restrictions and coexistence requirements for the z9 EC and z9 BC
also apply to the System z10 server.
For instance, large page support is not supported by z/OS when z/OS runs as a guest under z/VM on a System z10 server.  Review the restrictions and coexistence
requirements that were introduced for the z9 EC,
if you have not already done so, and take any necessary actions. <a id="idx205"></a><a id="idx206"></a></li>
<li><strong>Install the necessary z/OS service,
as indicated in PSP buckets.</strong> The appropriate PSP buckets are listed
in <a href="e0z3m100.htm#z10rmss">Recommended migration steps for a System z10 server</a> and are dependent on
the z/OS release you will run on the System z10 server and on the hardware support you already
have installed. If you reviewed the PSP buckets a long time ago, there
might have been additions since then, so ensure that any newly identified z/OS service has been installed.
To assist you in determining whether you have the recommended service
installed on your system, which is identified in these PSP buckets,
you can use the SMP/E REPORT MISSINGFIX command with a FIXCAT value
of &quot;IBM.Device.Server.z10-EC-2097&quot; or &quot;IBM.Device.Server.z10-BC-2098&quot;,
the Enhanced PSP Tool (<a href="http://www14.software.ibm.com/webapp/set2/psp/srchBroker">http://www14.software.ibm.com/webapp/set2/psp/srchBroker</a>),
or ServiceLink&rsquo;s PSP Service Extraction tool. <a id="idx207"></a><a id="idx208"></a><a id="idx209"></a>  

<p>If you use REPORT MISSINGFIX,
some FIXCAT values you can use for specific System z10 functions are:  
</p>
<ul>
<li>IBM.Device.Server.z10-BC-2098.CapacityProvisioning</li>
<li>IBM.Device.Server.z10-BC-2098.DecimalFloatingPoint</li>
<li>IBM.Device.Server.z10-BC-2098.MIDAW</li>
<li>IBM.Device.Server.z10-BC-2098.ParallelSysplexInfiniBandCoupling</li>
<li>IBM.Device.Server.z10-BC-2098.ServerTimeProtocol</li>
<li>IBM.Device.Server.z10-BC-2098.zAAP</li>
<li>IBM.Device.Server.z10-BC-2098.zHighPerformanceFICON</li>
<li>IBM.Device.Server.z10-BC-2098.zIIP</li>
<li>IBM.Device.Server.z10-EC-2097.CapacityProvisioning</li>
<li>IBM.Device.Server.z10-EC-2097.DecimalFloatingPoint</li>
<li>IBM.Device.Server.z10-EC-2097.MIDAW</li>
<li>IBM.Device.Server.z10-EC-2097.ParallelSysplexInfiniBandCoupling</li>
<li>IBM.Device.Server.z10-EC-2097.ServerTimeProtocol</li>
<li>IBM.Device.Server.z10-EC-2097.zAAP</li>
<li>IBM.Device.Server.z10-EC-2097.zHighPerformanceFICON</li>
<li>IBM.Device.Server.z10-EC-2097.zIIP</li></ul></li>
<li><strong>Run CFSizer.</strong> If you are moving your coupling facilities
and the coupling facility structures will be on later CFCC levels
than they were previously, run the Coupling Facility Structure Sizer
(CFSizer) tool to find out if you have to increase coupling facility
structure sizes. Prepare to make the necessary changes as indicated
by the tool. You can find the CFSizer tool at <a href=" http://www.ibm.com/systems/support/z/cfsizer/">http://www.ibm.com/systems/support/z/cfsizer/</a>.</li>
<li><strong>Plan for the System z10 fixed
HSA enhancement.</strong> With System z10 servers,
planning requirements are minimized by the availability of a fixed
HSA and introduction of the ability to seamlessly include events such
as creation of LPARs, inclusion of logical subsystems, changing logical
processor definitions in an LPAR, and introduction of cryptography
into an LPAR. For more information about this enhancement, see the
System z10 Redbooks&reg;.</li>
<li><strong>Decide on the steps you will take for your migration
to a System z10 server.</strong> 
As a guide, see <a href="e0z3m100.htm#z10rmss">Recommended migration steps for a System z10 server</a>. Be aware
of the following: 

<ul>
<li>You should review the cryptographic support you currently have
installed versus the support required for the functions you plan to
use on the System z10 server.
Several cryptographic support web deliverables have been made available
for various z/OS releases. The web deliverables listed in <a href="e0z3m100.htm#z10rmss">Recommended migration steps for a System z10 server</a> are the minimum web deliverable
level for the function specified. When a subsequent cryptographic
web deliverable is available for a particular z/OS level, the previous one is withdrawn. The
newer cryptographic web deliverable, however, includes the previous
function (when applicable) for that particular z/OS level. Note that you can use the newer
cryptographic web deliverables on servers before the System z10 server (that is, on System z9 and zSeries servers). 

<p>The level of cryptographic
support integrated in z/OS is ICSF FMID HCR7770 in z/OS V1R12. ICSF
FMID HCR7780 in z/OS V1R13, and ICSF FMID HBB7790 in z/OS V2R1.</p> 

<p>Where ICSF FMID HCR7770 is installed, the following coexistence
support is needed on other systems: 
</p>
<ul>
<li>For determining coexistence support needed on lower levels of
ICSF for HCR7780, use SMP/E FIXCAT IBM.Coexistence.ICSF.z/OS_V1R10-V1R12-HCR7780.</li>
<li>For determining coexistence support needed on lower levels of
ICSF for HCR7790, use SMP/E FIXCAT IBM.Coexistence.ICSF.z/OS_V1R11-V1R13-HCR7790.</li></ul></li>
<li>You can migrate to z/OS V2R1 before or after you migrate to a
System z10 server.</li></ul></li>
<li><strong>Upgrade your SCRT level if you want to process System z10 SMF data.</strong> SCRT V14.2.9 (Version
14 Release 2 Modification Level 9) provides support for the System z10 server.  If you collect SMF data
on a System z10 server and the
data will be processed by the SCRT, you must minimally use SCRT V14.2.9
to generate your SCRT reports.  If you do not need to process SMF
data from a System z10 server,
you are not required to download or use SCRT V14.2.9; you may continue
to use SCRT V14.1.0 or V14.2.0 until the next version upgrade of the
SCRT. SCRT V14.2.9 (or later) is available from the SCRT web site
at <a href=" http://www.ibm.com/systems/z/resources/swprice/subcap/scrt/">http://www.ibm.com/eserver/zseries/swprice/scrt/</a>.</li>
<li><strong>Review the new mnemonics introduced for the System z10.</strong> In support of the System z10 server, HLASM introduced new mnemonics for
the new machine instructions. The new mnemonics might collide with
(be identical to) the names of assembler macro instructions you use
or provide. In the event of such collisions, the HLASM default opcode
table (UNI) will treat specification of these names as instructions
when the PTF for APAR PK58463 is installed.  This will probably cause
assembler error messages and possibly cause generation of incorrect
object code. 

<p>If you write programs in assembler language, you should
compare the list provided in <cite>z/Architecture
Principles of Operation</cite>, SA22-7832, to the names of assembler
macro instructions you use or provide, to identify any such conflicts
or collisions that would occur following installation of the PTF for
HLASM APAR PK58463.</p> 

<p>To see the differences of supported mnemonics
before and after applying the PTF for APAR PK58463, assemble an END
statement with the PARM='OPTABLE(UNI,LIST)' option, and compare the
SYSPRINT files for the two assemblies.</p> 

<p>If a conflict is identified,
take one of the following actions:  
</p>
<ul>
<li>Change the name of your macro instruction.</li>
<li>Specify <samp class="xph">PARM='...OPTABLE(YOP)...'</samp> or some other,
earlier opcode table.</li>
<li>Specify a separate ASMAOPT file containing assembler options as
in the previous method. This method requires no changes to source
code or JCL.</li>
<li>Add <samp class="xph">*PROCESS OPTABLE(YOP)</samp> as the first statement
of your source program.</li>
<li>Specify the PROFILE option in either JCL or the ASMAOPT file,
and the specified or default member of the SYSLIB data set is copied
into the beginning of the source program.</li>
<li>If you must use both a new instruction and a macro with the same
name in an assembly, you can use the following technique, where <em>XXX</em> is
a sample mnemonic. (Assume that the default OPTABLE(UNI) is in effect.) 
<pre class="xmp"><code><em>XXX</em>   a,b       new instruction
PUSH  ACONTROL  save current optable definition
ACONTROL OPTABLE(YOP)   switch optable dynamically
<em>XXX</em>   r,s,t     macro invocation
POP   ACONTROL  restore previous definition
<em>XXX</em>   c,d       new instruction</code></pre></li></ul><p class="indatacontent">For more information about the HLASM opcode table, see <cite>HLASM Programmer&amp;apos;s Guide</cite>.</p></li></ol>
<h4 id="e0z3m100-gen12">Actions you can take after you order a System z10 server</h4>
<p>After you order but before you install your System z10 server, do the following:</p>
<ol type="1">
<li><strong>Use the CHPID Mapping Tool.</strong> As you might
have done with your z9 EC or z9 BC, use the CHPID Mapping Tool
to map logical CHPIDs to physical channels (PCHIDs) and create input
to HCD/IOCP for your System z10 server.
The tool is a workstation-based Java application
available from the Resource
Link web site (<a href=" http://www.ibm.com/servers/resourcelink">http://www.ibm.com/servers/resourcelink</a>).
For more information about this tool, refer to the web site.</li>
<li><strong>Plan for the changes in hardware memory granularity
on a System z10 server.</strong> The
minimum hardware memory granularity for LPAR assignment to central
storage elements (initial and reserved) and for z/OS memory reconfiguration is changed on System z10 servers. On a z9 EC, z9 BC,
z990, and z890 it is 64 MB, on a z10 EC
it is 256 MB, and on a z10 BC
it is 128 MB. Addressability is also increased to 8 TB on a z10 EC. For more information, see <cite>PR/SM Planning Guide</cite>. 


<p>If
your installation is set up to do central memory reconfiguration with z/OS, you might have to change
your RSU setting in parmlib member IEASYS<span class="synph"><span class="var">xx</span></span>. You can specify
RSU as a number, a percentage of all storage, or in MB (or GB or TB). <cite>z/OS MVS Initialization and Tuning Reference</cite> states
that while number values from 1-9999 are supported, it is recommended
that you use the megabyte, gigabyte, or terabyte format. If you currently
specify RSU as a number, such as <samp class="xph">RSU=10</samp> on a System z9 server, this would result in 640
MB assuming a partition with the largest element of 32 GB or less
of central storage. However, on a z10 EC
with the same amount of central storage, the result would be 2560
MB. If you specify an RSU in MB or GB, there will probably be less
of an impact but you need to understand that the values are rounded
to a multiple of 256 MB instead of 64 MB or 128 MB.</p>


<p>Note that
specifying an RSU value greater than the total amount of real storage
available on the system will cause message IAR026I THE RSU VALUE SPECIFIED
EXCEEDS THE TOTAL AMOUNT OF REAL STORAGE AVAILABLE ON THIS SYSTEM: <em>yyyyyyyy</em>M
to be issued by the system during IPL indicating an RSU overspecification
condition, and showing the amount of real storage available on the
system. This message will be followed by IAR006A INVALID {VRREGN|REAL|RSU}
PARM - RESPECIFY OR PRESS ENTER FOR THE DEFAULT prompting for a valid
RSU value. Special care should be given to select the right RSU value
for the system. A large RSU value can ultimately cause system performance
problems.</p></li></ol>
<h4 id="z10rmss">Recommended migration steps for a System z10 server</h4>
<p>This topic suggests the steps for migrating your same z/OS release level from your current
server to a System z10 server.
The steps are based on the assumption that you want to minimize the
amount of change (and therefore risk) and the amount of work required
to perform the migration.</p>
<p><strong>If your current z/OS release is V1R12, follow
these steps</strong>:</p>
<ol type="1">
<li>Install the service in the following PSP buckets: 


<ul>
<li>The z10 PSP bucket: 


<ul>
<li>For the z10 EC: upgrade 2097DEVICE,
subset 2097/ZOS</li>
<li>For the z10 BC: upgrade 2098DEVICE,
subset 2098/ZOS</li></ul></li>
<li>The z9 EC PSP bucket: upgrade
2094DEVICE, subset 2094/ZOS (if not already on a z9 EC or z9 BC)</li>
<li>The z990 PSP bucket: upgrade 2084DEVICE, subset 2084/ZOS (if not
already on a z990 or z890)</li></ul></li></ol>
<p><strong>If your current z/OS release
is V1R13, follow these steps</strong>:</p>
<ol type="1">
<li>Install the service in the following PSP buckets: 


<ul>
<li>The z10 PSP bucket: 


<ul>
<li>For the z10 EC: upgrade 2097DEVICE,
subset 2097/ZOS</li>
<li>For the z10 BC: upgrade 2098DEVICE,
subset 2098/ZOS</li></ul></li>
<li>The z9 EC PSP bucket: upgrade
2094DEVICE, subset 2094/ZOS (if not already on a z9 EC or z9 BC)</li>
<li>The z990 PSP bucket: upgrade 2084DEVICE, subset 2084/ZOS (if not
already on a z990 or z890)</li></ul></li></ol>
<p><strong>If your current z/OS release is V2R1, follow these steps</strong>:</p>
<ol type="1">
<li>Install the service in the following PSP buckets: 


<ul>
<li>The z10 PSP bucket: 


<ul>
<li>For the z10 EC: upgrade 2097DEVICE,
subset 2097/ZOS</li>
<li>For the z10 BC: upgrade 2098DEVICE,
subset 2098/ZOS</li></ul></li>
<li>The z9 EC PSP bucket: upgrade
2094DEVICE, subset 2094/ZOS (if not already on a z9 EC or z9 BC)</li>
<li>The z990 PSP bucket: upgrade 2084DEVICE, subset 2084/ZOS (if not
already on a z990 or z890)</li></ul></li></ol>
<p><strong>Tip for locating the correct service</strong>: To
simplify finding the appropriate PSP bucket and identifying which
PTFs listed in the PSP bucket need to be installed on your system,
use the SMP/E REPORT MISSINGFIX command in conjunction with the FIXCAT
type of HOLDDATA, as follows:</p>
<ol type="1">
<li>Acquire and RECEIVE the latest HOLDDATA onto your pre-z/OS V2R1
systems. Use your normal service acquisition portals or download the
HOLDDATA directly from <a href="http://service.software.ibm.com/holdata/390holddata.html">http://service.software.ibm.com/holdata/390holddata.html</a>.
Ensure you use the FULL file (last 730 days) to receive the FIXCAT
HOLDDATA, as the other files do not contain FIXCAT HOLDDATA.</li>
<li>Run the SMP/E REPORT MISSINGFIX command on your pre-z/OS V21R1
systems and specify a Fix Category (FIXCAT) value of &quot;IBM.Device.Server.z10-BC-2098&quot; or &quot;IBM.Device.Server.z10-EC-2097&quot;.
The report will identify any missing coexistence and fallback PTFs
for that system. For complete information about the REPORT MISSINGFIX
command, see <cite>SMP/E for z/OS Commands</cite>.</li>
<li>Periodically, you might want to acquire the latest HOLDDATA and
rerun the REPORT MISSINGFIX command to find out if there are any new
coexistence and fallback PTFs.</li></ol>
<h4 id="e0z3m100-gen13">Migration and exploitation considerations for System z10 functions</h4>
<ol type="1">
<li><strong>C/C++ ARCH(8) and TUNE(8) options</strong>: <a id="idx210"></a><a id="idx211"></a> The
ARCHITECTURE option of the XL C/C++ compiler selects the minimum level
of machine architecture on which your programs will run. Certain features
provided by the compiler require a minimum architecture level. ARCH(8)
exploits instructions available on System z10 servers.
For more information, see the ARCHITECTURE compiler option in <cite>z/OS XL C/C++ User's Guide</cite>.
The TUNE compiler option allows you to optimize your application for
a specific machine architecture within the constraints imposed by
the ARCHITECTURE option. The TUNE level must not be lower than the
setting in the ARCHITECTURE option. For more information, refer to
the TUNE compiler option in <cite>z/OS XL C/C++ User's Guide</cite>. 

<p><strong>Exploitation
restriction</strong>: Once programs exploit the ARCH(8) or TUNE(8) option,
the programs can only run on System z10 servers;
otherwise, an operation exception will occur. This is a consideration
for programs that will run on different server levels (System z9 and zSeries) during development, test, and production,
as well as during fallback or disaster recovery.</p> 
<div>
<div class="note-noindent" id="wq132">
<span class="notetitle">Note:</span> <span class="notebody">ARCH(7)
is the minimum level required to exploit decimal floating point support.
The resulting program objects can run on System z9 servers (depending on the MLC installed) as
well as on System z10 servers.</span></div></div></li>
<li><strong>HiperDispatch</strong>: <a id="idx212"></a> A new
HIPERDISPATCH=YES|NO parameter in parmlib member IEAOPT<span class="synph"><span class="var">xx</span></span>,
and on the SET OPT=<span class="synph"><span class="var">xx</span></span> command, controls
whether HiperDispatch is enabled or disabled for the system. The value
can be changed dynamically.  HiperDispatch defaults to disabled. Thus,
by default, your environment is not changed from a HiperDispatch perspective
when migrating from a pre-System z10 server
to a System z10 server.  Once
migration has completed, you can exploit the HiperDispatch function
of the System z10 server. 

<p>Because
HiperDispatch improves the performance of a System z10 system, a new health check (SUP_HIPERDISPATCH)
was added to verify that HiperDispatch is enabled. The new health
check is only added on System z10 systems.
WLM goal adjustment might be required when using this function. Review
and update your WLM policies as necessary. You might need to turn
off and on HiperDispatch while adjusting your WLM goals.</p></li>
<li><strong>Capacity Provisioning</strong>:  <a id="idx213"></a> An
installed On/Off CoD record is a necessary prerequisite for automated
control of temporary capacity through z/OS Capacity
Provisioning. Capacity Provisioning allows you to set up rules defining
the circumstances under which additional capacity should be provisioned
in order to fulfill a specific business need. The rules are based
on criteria, such as the maximum additional capacity that may be activated
for one or more workloads, and time and workload conditions. The workload
condition can identify a specific application by use of WLM service
classes. Capacity changes can be suggested or implemented automatically,
when authorized by policy. This support provides a fast response to
capacity changes and ensures sufficient processing power will be available
with the least possible delay even if workloads fluctuate. For more
information, see <cite>z/OS MVS Capacity Provisioning User&amp;apos;s
Guide</cite>.</li>
<li><strong>Large page support</strong>:  <a id="idx214"></a> A
change to the z/Architecture on
System z10 servers is designed
to allow memory to be extended to support large (1 MB) pages. Large
pages are used in addition to the existing 4 KB pages. The use of
large pages is expected to reduce memory management overhead for exploiting
applications. 

<p>Large page support is primarily of benefit for long-running
applications that are memory-access intensive. Large page support
is not recommended for general use. Short-lived processes with small
working sets are normally not good candidates for large pages.</p> 

<p>To
use large pages, you need to run z/OS V1R9
(or later) with the appropriate PTFs in a native System z10 LPAR. The support is not enabled if you are
running without the software support, are running on a prior generation
of server, or are running as a z/OS guest
under z/VM. Without the large
page support, page frames are allocated at the (current) 4 KB size.</p> 

<p>Furthermore, to exploit large page frames, a new LFAREA=xx%|xxxxxxM|xxxxxxG
parameter in parmlib member IEASYS<span class="synph"><span class="var">xx</span></span> must
be specified. This parameter cannot be changed dynamically.</p> 

<p>With
the installation of APAR OA32001, the calculation of the max value
of the LFAREA is changed. The LFAREA max value is now less than the
old max LFAREA value. The maximum amount of real storage that can
be used to back large pages is now (80% of the online storage available
at IPL) minus 2 GB. Make sure the LFAREA value you specify in the
IEASYS<span class="synph"><span class="var">xx</span></span> member is less than the new max
value available in the system. You can specify LFAREA as a percentage
of all storage, or in MB or GB. Specifying a percentage for the LFAREA
parameter is now also calculated as (the percent of the online storage
available at IPL) minus 2 GB. Special care should be given to select
the right LFAREA value for the system. See <cite>z/OS MVS Initialization and Tuning Reference</cite> and
DOC APAR OA34024 for information about valid specification of the
LFAREA parameter.</p> 

<p> </p>
<div>
<div class="note-noindent" id="wq133">
<span class="notetitle">Note:</span> <span class="notebody">
<ol type="a">
<li>You must apply the PTF for APAR OA31116 to z/OS V1R11 and z/OS V1R12
to use the command <span class="synph"><span class="kwd">DISPLAY VIRTSTOR,LFAREA</span></span> to
find the allocation status of LFAREA.</li>
<li>If you do not want large frame support, do not use LFAREA=
to exploit large page frames. Starting with z/OS V2R1, when you specify
LFAREA=0M in IEASYSxx parmlib member, the following message is issued: <samp class="xph">IAR048I
LFAREA=0M WAS PROCESSED WHICH RESULTED IN 0 1MB PAGES AND 0 2GB PAGES.</samp></li></ol></span></div></div></li>
<li><strong>Coupling facility level 16</strong>: Service time for CF duplexing
is improved, shared IMS and MQ
list notification is improved, and the structure increment size is
increased from 512 KB to 1 MB.</li>
<li><strong>Parallel Sysplex InfiniBand
(PSIFB) coupling links</strong>: <a id="idx215"></a><a id="idx216"></a><a id="idx217"></a> InfiniBand
coupling links provide an additional option for your Parallel Sysplex cluster on System z10 and System z9. When used in the data center, InfiniBand coupling
links can replace Integrated Cluster Bus-4 (ICB-4) and InterSystem
Channel-3 (ISC-3) links. 
<div>
<div class="note-noindent" id="wq135">
<span class="notetitle">Note:</span> <span class="notebody"> Be sure to conduct performance
analyses when replacing one type of coupling link with another.</span></div></div> 

<p>Coupling
facilities can now be separated by up to 150 meters (492 feet).</p> 

<p>InfiniBand
coupling links use fiber optic cabling containing 12 pairs (12x) of
fiber compared to one pair (1x) of fiber used with ISC-3 fiber optic
cabling. InfiniBand coupling links support double data rate (DDR)
when a z10 EC is communicating
with another z10 EC. InfiniBand
coupling links support single data rate (SDR) when a z10 EC is communicating with a z9 EC dedicated CF or z9 BC
Model S07 dedicated CF. When the InfiniBand coupling link is z10 EC-to-z10 EC, the link auto-negotiates
to 6 GBps. A z10 EC system auto-negotiates
to 3 Gbps when connected to a z9 EC
or z9 BC dedicated coupling facility.</p> 
<div>
<div class="note-noindent" id="wq136">
<span class="notetitle">Note:</span> <span class="notebody">The
InfiniBand link data rate of 6 Gbps or 3 Gbps does not represent the
performance of the link. The actual performance is dependent upon
many factors including latency through the adapters, cable lengths,
and the type of workload. With InfiniBand coupling links, while the
link data rate may be higher than that of ICB, the service times of
coupling operations are greater, and the actual throughput may be
less than with ICB links.</span></div></div> 

<p>Refer to the <em>Coupling Facility
Configuration Options</em> white paper for a more specific explanation
of when to continue using the current ICB technology versus migrating
to InfiniBand coupling links. The white paper is available at <a href="http://www.ibm.com/systems/z/advantages/pso/whitepaper.html">http://www.ibm.com/systems/z/advantages/pso/whitepaper.html</a>.</p> 

<p>A
new infrastructure was created to support an InfiniBand coupling link
environment. Host channel adapter optical (HCA-O) fanouts have been
introduced for System z10 and
System z9 dedicated coupling
facilities. The HCA-O fanouts, with two ports per fanout, reside on
the front of each processor book. The fiber optic cables are plugged
directly into the front of the HCA-O fanouts: 
</p>
<ul>
<li>HCA2-O fanout for System z10 servers</li>
<li>HCA1-O fanout for z9 EC and z9 BC Model S07 dedicated coupling
facilities</li></ul> 

<p>There is a new physical definition to associate with
a channel path identifier with an adapter identification. Unlike channels
installed in an I/O cage, which are identified by a physical channel
path identifier (PCHID) number related to their physical location,
HCA-O fanouts and ports are identified by an adapter identification
(AID) value that is determined by its physical location. The AID must
be used to assign a CHPID to the fanout in the hardware configuration
definition. The CHPID assignment is done by associating the CHPID
to an AID and port. The AID assigned to a fanout can be found in the
PCHID report provided for each new server or for upgrades on System z10 and System z9 servers.</p> 

<p>There is also a new CHPID type
CIB (coupling using InfiniBand). CHPID type CIB is common for System z10 and System z9 servers.</p> 

<p>On System z10 and System z9 servers,
the design allows up to 16 CHPIDs to be defined across the two ports
on each HCA-O fanout. This can reduce the number of coupling links;
physical coupling links can be shared by multiple sysplexes. For example,
this capability allows for one CHPID to be directed to one coupling
facility and a second CHPID to be directed to a separate coupling
facility on the same target server, using the same port. An increased
number of CHPIDs per physical link can help to facilitate consolidation
of ISC-3 links onto InfiniBand coupling links.</p> 

<p>InfiniBand coupling
links can also be used to exchange timekeeping messages for Server
Time Protocol (STP).</p> 

<p>You can choose the coupling links that
best suit your business needs: IC, ICB, IFB, or ISC-3.</p></li></ol>
<h3 id="dt2mg230">Ensure you are running on supported servers and storage controllers</h3><a id="idx218"></a>
<p>z/OS V2R1 runs on these IBM System z servers:  
</p>
<ul>
<li>IBM zEnterprise EC12 (zEC12)</li>
<li>IBM zEnterprise BC12 (zBC12)</li>
<li>IBM zEnterprise 196 (z196)</li>
<li>IBM zEnterprise 114 (z114)</li>
<li>IBM System z10 (z10 EC, z10 BC) (<strong>Note:</strong> withdrawn from marketing)</li>
<li>IBM System z9 (z9 BC, z9 EC) (<strong>Note:</strong> withdrawn from marketing)</li></ul>
<p>In addition, z/OS V2R1 supports these and later IBM storage control
units: 
</p>
<ul>
<li>3990 Model 3 and 3990 Model 6</li>
<li>9393</li>
<li>2105</li>
<li>2107</li>
<li>2421</li>
<li>2422</li>
<li>2423</li>
<li>2424</li></ul>
<p>If you try to use an unsupported control unit for z/OS V2R1, you
receive the following error condition during both IPL/NIP processing
and VARY ONLINE command processing: </p>
<pre class="xmp"><code>IEA434I (nnnn) ONLINE IS NOT ALLOWED, INVALID CONTROL UNIT MODEL </code></pre>
<p>As of z/OS V2R1, the following IBM servers are no longer supported:
</p>
<ul>
<li>IBM eServer zSeries 990 (z990)</li>
<li>IBM eServer zSeries 890 (z890)</li>
<li>IBM eServer zSeries 900 (z900)</li>
<li>IBM eServer zSeries 800 (z800)</li></ul>
<table id="wq137" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Multiple</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>As of z/OS V2R1 the z990, z890, z900, and z800
servers are no longer supported.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS VR13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Anytime</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use any of the servers that are
no longer supported.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>This consistent coexistence, migration, and
fallback policy applies to release migrations for all configurations,
whether they are:

<ul>
<li>Single system configurations </li>
<li>Individual systems within a multisystem configuration </li>
<li>Cases where a simultaneous IPL is used to migrate all systems
in a multisystem configuration at the same time</li></ul></td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ol type="1">
<li>Determine whether the servers and control units you use are supported.
If you have a question about support for any devices not listed, contact
your IBM representative.</li>
<li>Install replacement servers. Move data that is stored on unsupported
servers to the supported servers. Detach unsupported servers from
the system and delete their corresponding definitions from the input/output
definition file (IODF).</li></ol>
<p><strong>Reference</strong>: For more information, see <cite>Release memorandum
- RFA 58183 - 04/15/13 (IBM Guide 27.10)</cite>.</p>
<h3 id="at3ruio">Replace unsupported devices</h3>
<p><strong>Description</strong>: You should remove and replace
devices that were supported by earlier releases but cannot be used
with the current release of z/OS because they are no longer supported.<a id="idx219"></a><a id="idx220"></a></p>
<table id="wq139" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Anytime.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use any of the devices that are
no longer supported.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>Replacement devices as necessary.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Determine whether the devices you use are supported. A list of
supported I/O devices is in the topic about  in <cite>z/OS Planning
for Installation</cite>.
If you have a question about support for any devices not listed, contact
your IBM representative.</li>
<li>Install replacement devices. Move data that is stored on unsupported
devices to the supported devices. Detach unsupported devices from
the system and delete their corresponding device definitions from
the input/output definition file (IODF).</li></ol>
<p><strong>Reference information</strong>: 

</p>
<ul>
<li>For a list of I/O devices that are supported, see the topic about  in <cite>z/OS Planning
for Installation</cite>.</li>
<li>For information about deleting device definitions from the IODF,
see <cite>z/OS HCD User&amp;apos;s Guide</cite>.</li></ul>
<h3 id="au3ndv">Provide for new device installations</h3>
<p><strong>Description</strong>: The hardware configuration of
your processors and I/O devices determines how many devices you can
attach to your system. z/OS supports attachment of up to 65,280 devices,
each with up to eight access paths. <a id="idx221"></a></p>
<table id="wq141" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Anytime.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are going to use new devices
with z/OS V2R1 and later.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>Dependent upon the new devices used.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: The following are general
considerations related to I/O device support. 

</p>
<ul>
<li><em>Attaching devices through HCD.</em> You can
define, or attach, new devices to your system through the interactive
panels of the Hardware Configuration Definition (HCD) base element.
HCD has dynamic I/O capabilities, changing hardware definitions without
the need for an IPL or hard power-on reset. 


<p>Any time you make changes
to your I/O configuration, you need to use HCD to modify your system's
I/O definition file (IODF). You should also update the input/output
configuration data set (IOCDS) when you run HCD to ensure that the
configuration information is consistent across the software and microcode.</p></li>
<li><em>Operating modes.</em> Most devices attached
to z/OS operate in full function mode, that is, all features on the
device are compatible with, and usable on, the operating system. Some
of these features include:


<ul>
<li>For DASD devices: dynamic path reconnection, extended count-key-data
operation, and caching and cache-related facilities</li>
<li>For tape devices: cartridge stack loading and data compaction</li></ul>


<p>Some devices also operate in compatibility mode, which allows
you to simulate the function of another device or model. Compatibility
mode causes the device to function like a different device of the
same type, ignoring some or all of the additional features the device
might have. This allows you to migrate between devices with minimal
impact on programs that have device dependencies.</p></li>
<li><em>UCB virtual storage constraint relief.</em> Each
device attached to the system has one or more UCBs associated with
it. You have the option to define UCBs either above or below the 16
MB line by specifying the LOCANY parameter on the Hardware Configuration
Definition (HCD) panel. The system programmer should review the contents
of the link pack area (LPA) list to determine whether to remove or
move libraries to gain virtual storage constraint relief.<a id="idx222"></a><a id="idx223"></a></li>
<li><em>Hardware maintenance.</em> Some devices require
a specific level of hardware maintenance to operate properly on a z/OS system. DFSMS software support for new
hardware devices might also require the installation of PTFs.</li></ul>
<p><strong>Reference information</strong>: 

</p>
<ul>
<li>For a summary of the most commonly-used I/O devices supported
by z/OS that are also directly supported by DFSMS functions, see the topic
about  in <cite>z/OS Planning
for Installation</cite>.
 If you have a question about support for a device that is not listed,
contact your IBM representative.</li>
<li>For more information about HCD, see <cite>z/OS HCD Planning</cite>.</li>
<li>For information about working with IODFs, see <cite>z/OS HCD User&amp;apos;s Guide</cite>.</li></ul>
<h3 id="au3cpfl">Update your CFRM policy with coupling facility structure size
changes</h3>
<p>[[[[ Technical contact: David H Surman/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: If you are migrating to a new
level of coupling facility control code (CFCC), you have to make appropriate
coupling facility structure size updates in the z/OS coupling facility resource management (CFRM)
policy.</p>
<table id="wq142" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx224"></a><a id="idx225"></a><a id="idx226"></a><strong>Element or feature</strong>:</td>
<td>Multiple.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Anytime.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are migrating to a new CFCC level.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>See <a href="http://www-03.ibm.com/systems/z/advantages/pso/cftable.html">http://www.ibm.com/systems/z/advantages/pso/cftable.html </a>.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If you are migrating to a
new CFCC level, do the following:</p>
<ol type="1">
<li>Run the Coupling Facility Structure Sizer (CFSizer) tool. This
tool sizes structures, taking into account the amount of space needed
for the current CFCC levels. The tool sizes for the most currently
available level; you might find that the results are oversized if
you use an earlier CFCC level. You can find the tool at <a href=" http://www.ibm.com/systems/support/z/cfsizer/">http://www.ibm.com/systems/support/z/cfsizer/</a>.<a id="idx227"></a><a id="idx228"></a><a id="idx229"></a>



<p>Alternatively, you can run an as-is batch utility
program called SIZER after you have brought a new CFLEVEL coupling
facility into use in your configuration. SIZER examines your currently
allocated coupling facility structures and recalculates the size that
should be used for them with the new later-CFLEVEL coupling facility.
The as-is SIZER utility is available as a zipped package that
you can download from <a href="http://www.ibm.com/systems/support/z/cfsizer/altsize.html">http://www.ibm.com/systems/support/z/cfsizer/altsize.html </a>.</p></li>
<li>Update the CFRM policy with the size modifications that are needed.</li>
<li>Activate the updated CFRM policy so that it becomes the active
policy governing structure allocation in the sysplex.</li></ol>
<p><strong>Reference information</strong>: For a detailed description
of coupling facility code levels and the processors that support those
levels, see <a href="http://www.ibm.com/systems/z/pso/cftable.html">http://www.ibm.com/systems/z/advantages/pso/cftable.html </a>.<a id="idx230"></a><a id="idx231"></a><a id="idx232"></a></p>
<h1 id="dt2mg235">Migration from z/OS V1R13</h1>
<div>
<p>Part 2 describes those actions for anyone who is migrating
from z/OS V1R13.</p></div>
<p>ANY COMMENTS YOU MAKE IN CHAPTER
3 FOR ACTION ITEMS MARKED AS 'APPLIES TO MIGRATION' FROM BOTH V1R13
AND V1R12 WILL APPLY TO THE ACTIONS HERE IN CHAPTER 2.</p>
<h2 id="av1pars2">Sysplex migration actions</h2>
<p>This topic summarizes actions for you to take if you are migrating
systems that are members of a base sysplex or Parallel Sysplex configuration.</p>
<h3 id="e0z3m100-gen19">Sysplex actions related to hardware upgrades</h3><a id="idx233"></a>
<table id="wq144" width="100%" summary="" border="1" frame="border" rules="all">
<thead valign="bottom">
<tr>
<th id="wq145" width="75%" align="left" valign="top">Title of migration action</th>
<th id="wq146" width="25%" align="left" valign="top">Page or topic</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq145"><a href="e0z3m100.htm#au3cpfl">Update your CFRM policy with coupling facility structure size
changes</a></td>
<td headers="wq146"><a href="e0z3m100.htm#au3cpfl">Update your CFRM policy with coupling facility structure size
changes</a></td>
</tr>
<tr>
<td headers="wq145"><a href="e0z3m100.htm#mignext">Migrate to an IBM zEnterprise z196 or z114 server</a></td>
<td headers="wq146"><a href="e0z3m100.htm#mignext">Migrate to an IBM zEnterprise z196 or z114 server</a></td>
</tr>
<tr>
<td headers="wq145"><a href="e0z3m100.htm#migrz10">Migrate to a System z10 server</a></td>
<td headers="wq146"><a href="e0z3m100.htm#migrz10">Migrate to a System z10 server</a></td>
</tr>
</tbody>
</table>
<h3 id="e0z3m100-gen20">Sysplex actions to perform before installing z/OS V2R1</h3><a id="idx234"></a><a id="idx235"></a><a id="idx236"></a><a id="idx237"></a><a id="idx238"></a>
<table id="wq147" width="100%" summary="" border="1" frame="border" rules="all">
<thead valign="bottom">
<tr>
<th id="wq148" width="12%" align="left" valign="bottom">Element or feature</th>
<th id="wq149" width="66%" align="left" valign="bottom">Title of migration action</th>
<th id="wq150" width="21%" align="left" valign="bottom">Page or topic</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq148">Multiple</td>
<td headers="wq149"><a href="e0z3m100.htm#coxptfs">Install coexistence and fallback PTFs</a></td>
<td headers="wq150"><a href="e0z3m100.htm#coxptfs">Install coexistence and fallback PTFs</a></td>
</tr>
<tr>
<td headers="wq148">DFSMSdfp</td>
<td headers="wq149"><a href="e0z3m100.htm#ax3eisc">DFSMSdfp:
Back up SMS control data sets</a></td>
<td headers="wq150"><a href="e0z3m100.htm#ax3eisc">DFSMSdfp:
Back up SMS control data sets</a></td>
</tr>
<tr>
<td headers="wq148">Distributed File Service</td>
<td headers="wq149"><a href="e0z3m100.htm#filesyszfs">zFS: Ensure sysplex=filesys is available on all zFS R11 and
R12 systems in a shared file system environment</a></td>
<td headers="wq150"><a href="e0z3m100.htm#filesyszfs">zFS: Ensure sysplex=filesys is available on all zFS R11 and
R12 systems in a shared file system environment</a></td>
</tr>
</tbody>
</table>
<h3 id="e0z3m100-gen21">Sysplex actions to perform before the first IPL of z/OS V2R1</h3>
<p>None.</p>
<p></p>
<table id="wq151" width="100%" summary="" border="1" frame="border" rules="all">
<thead valign="bottom">
<tr>
<th id="wq152" width="10%" align="left" valign="bottom"><a id="idx239"></a><a id="idx240"></a><a id="idx241"></a><a id="idx242"></a><a id="idx243"></a><a id="idx244"></a><a id="idx245"></a>Element
or feature</th>
<th id="wq153" width="68%" align="left" valign="bottom">Title of migration action</th>
<th id="wq154" width="21%" align="left" valign="bottom">Page or topic</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq152">BCP</td>
<td headers="wq153"><a href="e0z3m100.htm#oa35357">Change value for ARM restart processing</a></td>
<td headers="wq154"><a href="e0z3m100.htm#oa35357">Change value for ARM restart processing</a></td>
</tr>
<tr>
<td headers="wq152">BCP</td>
<td headers="wq153"><a href="e0z3m100.htm#dxcfmsg">Modify automation that references output from D XCF,SYSPLEX
console commands</a></td>
<td headers="wq154"><a href="e0z3m100.htm#dxcfmsg">Modify automation that references output from D XCF,SYSPLEX
console commands</a></td>
</tr>
<tr>
<td headers="wq152">BCP</td>
<td headers="wq153"><a href="e0z3m100.htm#operloge">Accommodate OPERLOG EMCS console name change</a></td>
<td headers="wq154"><a href="e0z3m100.htm#operloge">Accommodate OPERLOG EMCS console name change</a></td>
</tr>
<tr>
<td headers="wq152">JES3</td>
<td headers="wq153"><a href="e0z3m100.htm#autoflsh">Avoid redundant *S main,FLUSH command in response to XCF messages</a></td>
<td headers="wq154"><a href="e0z3m100.htm#autoflsh">Avoid redundant *S main,FLUSH command in response to XCF messages</a></td>
</tr>
</tbody>
</table>
<h3 id="e0z3m100-gen22">Sysplex actions to perform after the first IPL of z/OS V2R1</h3>
<p>None.</p>
<table id="wq155" width="100%" summary="" border="1" frame="border" rules="all">
<thead valign="bottom">
<tr>
<th id="wq156" width="20%" align="left" valign="bottom"><a id="idx246"></a><a id="idx247"></a><a id="idx248"></a><a id="idx249"></a><a id="idx250"></a><a id="idx251"></a><a id="idx252"></a>Element
or feature</th>
<th id="wq157" width="60%" align="left" valign="bottom">Title of migration action</th>
<th id="wq158" width="18%" align="left" valign="bottom">Page or topic</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq156">SDSF</td>
<td headers="wq157"><a href="e0z3m100.htm#wbmqsdsf">Update configuration for sysplex support</a></td>
<td headers="wq158"><a href="e0z3m100.htm#wbmqsdsf">Update configuration for sysplex support</a></td>
</tr>
</tbody>
</table>
<h2 id="aa1bcp">BCP migration actions</h2>
<p>This topic describes migration actions for the base element BCP
(Base Control Program).</p>
<p>REVIEWERS: A new migration action for WLM will be included
in the next review.</p>
<h3 id="e0z3m100-gen98">BCP actions to perform before installing z/OS V2R1</h3><a id="idx253"></a>
<p>This topic describes BCP migration actions that you can perform
on your current (old) system. You do not need the z/OS V2R1 level of code to make these changes,
and the changes do not require the z/OS V2R1
level of code to run once they are made.</p>
<p>PLACEHOLDER FOR POSSIBLE WLM ACTION</p>
<p><a href="e0z3m100.htm#edumpds">Evaluate your stand-alone dump data set allocations and your
IPCS processing of them</a></p>
<p><a href="e0z3m100.htm#switch_id">Move from the Consoles Tracking Facility to the Generic Tracker</a></p>
<p><a href="e0z3m100.htm#dt2mg280">Move BCPii API calls into your application instead of in BCPii
ENF exits</a></p>
<p><a href="e0z3m100.htm#dt2mg281">Update code that invokes the IOSSPOF macro in a PSW key of
0-7</a></p>
<p><a href="e0z3m100.htm#dt2mg282">Handle changes to length of field EEPLEVENTSPECIFICINFO in
control block IXLYEEPL</a></p>
<p><a href="e0z3m100.htm#mvspgser">Change references to PGSER PROTECT/UNPROTECT</a></p>
<p><a href="e0z3m100.htm#warnund">Consider exploiting WARNUND for new IEASYS<em>xx</em> statements</a></p>
<p><a href="e0z3m100.htm#sodbcpii">Migrate from SNMP to z/OS BCPii for communication to the HMC
or SE for z/OS Capacity Provisioning support</a></p>
<h4 id="edumpds">Evaluate your stand-alone dump data set allocations and your
IPCS processing of them</h4>
<p>[[[[ Technical contact: Purvi Patel/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: As your applications grow in
size and use ever greater amounts of storage, you should evaluate
whether the DASD allocated for your stand-alone dump data continues
to be adequate. <a id="idx254"></a><a id="idx255"></a></p>
<p>In z/OS V1R6, support was introduced for extended-format
sequential data sets, a form of data set that is SMS-managed and can
occupy more than 64 K tracks per volume. In z/OS V1R7, this support
was supplemented with support for large format sequential data sets
(DSNTYPE=LARGE), a form of data set that is essentially the same as
conventional sequential data sets except that more than 64 K tracks
may be spanned per volume. If your stand-alone dump data sets are
spread over more volumes than you want, both types of support can
help you gain better control over the number of volumes used for each
stand-alone dump data set.</p>
<table id="wq159" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because of changes that
have been made to stand-alone dump processing (that reorder dump records
with the intent of recording more important data early), and especially
recommended if you deploy any LPARs with significantly more main storage
than previously used.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 

</p>
<ul>
<li>Use multivolume stand-alone dump data sets. Adjust the number
of volumes and their separation to achieve tolerable stand-alone dump
capture times.</li>
<li>Use extended-format sequential data sets or large format
sequential data sets. Copy their contents to an extended-format,
compressed, striped data set using the IPCS COPYDUMP subcommand before
analysis. Use the same or a larger striping factor than you used for
your stand-alone dump data sets. Dump data sets to which stand-alone
dump can write may be neither compressed nor striped, but both attributes
are advantageous for the target of the copy operation. Starting
with z/OS V1R12, stand-alone dump data sets can be placed in
track-managed space as well as cylinder-managed space
on Extended Address Volumes (EAV).</li>
<li>Use a large CISIZE and striping for IPCS dump directories, and
use blocking, striping, and compression for the stand-alone dump data
set. Very large stand-alone dumps might require that you define your
directory with the extended addressing attribute, allowing it to hold
more than 4 GB.


<p><strong>Tips</strong>: Control interval sizes
less than 24K have been shown to be more vulnerable to fragmentation
when used as IPCS dump directories, and IPCS performance can be degraded
when such fragmentation occurs. In this background, warning message
BLS21110I will be issued and you might recreate the DDIR by using
the CLIST BLSCDDIR.
</p>
<pre class="xmp"><code>BLS21110I CISIZE(cisize) is less than 24K. It may degrade IPCS performance</code></pre></li></ul>
<p><strong>Reference information</strong>: 

</p>
<ul>
<li>For information about dump data set allocation, extended-format
sequential data sets, large format sequential data sets, and multivolume
dump data sets, see <cite>z/OS MVS Diagnosis: Tools and Service Aids</cite>.</li>
<li>For , see <cite>z/OS Problem Management</cite>.</li></ul>
<h4 id="switch_id">Move from the Consoles Tracking Facility to the Generic Tracker</h4><a id="idx256"></a><a id="idx257"></a><a id="idx258"></a><a id="idx259"></a>
<p> </p>
<div>
<div class="note-noindent" id="wq160">
<span class="notetitle">Note:</span> <span class="notebody">This action will be finalized in the 3rd draft review of
Migration V2R1.</span></div></div>
<p>[[[[ Contributing writer: Debra A Quick/Somers/IBM@IBMUS
]]]] [[[[ Technical contact: Ulrich Thiemann/Rochester/IBM@IBMUS]]]]</p>
<p><strong>Description</strong>: Before z/OS V2R1, the Console Tracking Facility
was used to track and flag the continued use of one specific obsolete
system function. Starting with z/OS V2R1, the Console Tracking Facility
is being replaced with a new enhanced Generic Tracker. The Console
Tracker callable service CNZTRKR is being kept for compatibility,
but it internally routes the data to the Generic Tracker infrastructure.
A corresponding Generic Tracker callable service GTZTRACK is being
introduced; it is suggested that you use it instead of CNZTRKR. Additionally,
GTZQUERY is introduced in z/OS V2R1 as a programmatic interface to
retrieve tracking data. As of z/OS V2R1, support for the Console Tracker
parmlib member, CNIDTRxx, is no longer provided. The Generic Tracker
accepts GTZPRMxx parmlib members, and a tool to convert CNIDTRxx to
the Generic Tracker GTZPRMxx is also provided.<a id="idx260"></a></p>
<table id="wq161" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if the Console
Tracker commands are not issued manually and appear in scripts or
automation. It is assumed that the retired Console Tracker commands
are typically issued manually and for diagnostic purposes only, not
in any scripts or automation tools. The callable service CNZTRKR,
compiled into executable programs continues to be supported and the
internal routing of any data passed to CNZTRKR and the Generic Tracker
will be transparent to the existing CNZTRKR caller.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  Instead of using COMMNDxx, use
the new system parameter GTZ (in IEASYSxx) to specify a GTZPRMxx member
that specifies the SETGTZ TRACKING,ON command. Instead of the DISPLAY
command, consider using utility GTZPRINT or a user-written program
with the service GTZQUERY to retrieve, store, and process current
tracking data.
</p>
<ul>
<li>Use the Generic Tracker commands manually on the console if needed.</li>
<li>Use system parameter GTZ in IEASYSxx to specify a GTZPRMxx member
that specifies SETGTZ TRACKING,ON.</li>
<li>Use GTZPRINT or a user-written program using service GTZQUERY
to retrieve, store, and process current tracking data.</li>
<li>Use GTZPRMxx parmlib members and the conversion tool
to generate GTZPRMxx from CNIDTR<span class="synph"><span class="var">xx</span></span>.</li>
<li>Convert your code to use GTZTRACK.</li></ul>
<p>Also examine the WTOR replies in the AUTOR00 parmlib member.
See <a href="e0z3m100.htm#dt2mg300">Review the list of WTORs in parmlib member AUTOR00</a>.</p>
<p><strong>Reference information</strong>: 
</p>
<ul>
<li>For details about SETGTZ, SET GTZ, DISPLAY GTZ, see <cite>z/OS MVS System Commands</cite> and
DOC APAR OA34738.</li>
<li>For details about GTZTRACK and GTZQUERY, see <cite>z/OS MVS Programming: Assembler Services
Reference ABE-HSP</cite>.</li>
<li> For details about the new Generic Tracker, see <cite>z/OS MVS Planning: Operations</cite>.</li>
<li>For details about GTZPRMxx and IEASYSxx GTZ=, see <cite>z/OS MVS Initialization and Tuning Reference</cite>.</li></ul>
<h4 id="dt2mg280">Move BCPii API calls into your application instead of in BCPii
ENF exits</h4><a id="idx261"></a><a id="idx262"></a>
<p>[[[[ Contributing writer: Rita M Beisel/Poughkeepsie/IBM
]]]] [[[[ Technical contact: Stephen Warren/Poughkeepsie/IBM ]]]]</p>
<p><strong>Description</strong>: As stated in various IBM publications, non-SRB
ENF exits need to avoid time-consuming processing. Coding an HWIEVENT
ENF exit to execute BCPii APIs may result in multiple problems, such
as delays with BCPii event notification processing when BCPii services
are simultaneously being invoked.  Starting with z/OS V1R12 and later,
BCPii enforces this restriction, and BCPii API calls made from within
a BCPii ENF exit are now rejected with return code HWI_UNSUPPORTED_ENVIRONMENT
are now rejected with return code HWI_UNSUPPORTED_ENVIRONMENT.</p>
<table id="wq162" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12 without APAR OA38117
applied to either release.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have coded a BCPii API call from
your ENF exit.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>BCPii API calls made from within a BCPii ENF
exit are now rejected with return code HWI_UNSUPPORTED_ENVIRONMENT.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If you have coded a BCPii API call from your
ENF exit, move the BCPii API call into your application and have the
BCPii ENF exit post the application when the event occurs. Your application
program may now issue the BCPii API call from the user's thread.</p>
<p>For an example of how to code a BCPii ENF exit, see the
sample ENF event exit HWIXMCX1 in SYS1.SAMPLIB.</p>
<p><strong>Reference information:</strong> For additional information, see <cite>z/OS MVS Programming: Callable Services
for High-Level Languages</cite>.</p>
<h4 id="dt2mg281">Update code that invokes the IOSSPOF macro in a PSW key of
0-7</h4><a id="idx263"></a>
<p>[[[[ Contributing writer: Rita M Beisel/Poughkeepsie/IBM
]]]] [[[[ Technical contact: Marisa N Freidhof/Poughkeepsie/IBM ]]]]</p>
<p><strong>Description</strong>: The IOSSPOF macro changed to conditionally
obtain the returned SPOFAREA in a different subpool depending on the
caller's PSW key. This may cause the caller, depending on their current
PSW key, to be required to change to a different PSW key if they want
to update the storage. In addition, certain PSW key callers can no
longer rely on the storage automatically being freed when the task
ends. The subpool number continues to be returned in the SPOFAREA_SUBPOOL
so that it can be used when the storage is freed.</p>
<p>The specific changes are:
</p>
<ul>
<li>Key 0-7 callers: The returned SPOFAREA mapped by IOSDSPOF is obtained
in subpool 252, which is key 0 storage, non-fetch-protected, and is
associated with the jobstep task.</li>
<li>Key 8-15 callers: The returned SPOFAREA mapped by IOSDSPOF continues
to be obtained in subpool 1, which is fetch-protected storage with
a key equal to the TCB key and is associated with the issuing task.</li></ul>
<p>The specific restrictions are:
</p>
<ul>
<li>Key 0-7 callers cannot rely on the SPOFAREA storage automatically
being freed when the task ends. The area must now be explicitly freed
and the caller must meet the state, key, and APF-authorization requirements
for freeing from subpool 252.</li>
<li>Key 1-7 callers must change to Key 0 in order to update the returned
SPOFAREA storage.</li>
<li>Key 8-15 callers must be in the PSW key of the TCB in order to
access the SPOFAREA storage.</li></ul>
<table id="wq163" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have code that invokes the IOSSPOF
macro in a PSW key of 0-7.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: For any program that invokes the IOSSPOF
macro in a PSW key of 0-7, ensure the following restrictions are followed:
</p>
<ul>
<li>Key 0-7 callers: Because the subpool used for the SPOFAREA has
changed from being associated with the issuing task to being associated
with the jobstep task, be sure to free the storage if your task is
not the jobstep task. In addition, make sure your storage-free invocation
meets the state, key, and APF-authorization requirements for freeing
from subpool 252.</li>
<li>Key 1-7 callers: If the program attempts to write to the returned
SPOFAREA, the program must switch to key 0 to update the area.</li></ul>
<p><strong>Reference information:</strong> For additional information, see <cite>z/OS MVS Programming: Authorized Assembler Services
Reference, Volume 2 (EDT-IXG)</cite>.</p>
<h4 id="dt2mg282">Handle changes to length of field EEPLEVENTSPECIFICINFO in
control block IXLYEEPL</h4><a id="idx264"></a>
<p>TO BE PROVIDED IN NEXT DRAFT REVIEW</p>
<p><strong>Description</strong>:</p>
<table id="wq164" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td></td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<p><strong>Reference information:</strong></p>
<h4 id="mvspgser">Change references to PGSER PROTECT/UNPROTECT</h4><a id="idx265"></a><a id="idx266"></a><a id="idx267"></a>
<p></p>
<p>[[[[ Writer: Joshua Horton/Poughkeepsie/IBM
... Technical contact: David Hom/Poughkeepsie/IBM ]]]]</p>
<p><strong>Description</strong>: In z/OS V2R1 the MVS RSM PGSER PROTECT/UNPROTECT
macro has been changed to issue an ABEND in response to an attempt
to protect or unprotect the read-only nucleus that is backed by large
pages. In response, RSM issues abend code X&rsquo;18A&rsquo; and reason code X&rsquo;FF070411&rsquo;
(for PROTECT) or X&rsquo;FF080411&rsquo; (for UNPROTECT).</p>
<table id="wq165" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12 or z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if programs exist that use the PGSER PROTECT/UNPROTECT
macro to specify the applicable virtual storage range.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ol type="1">
<li>Search for programs that use the PGSER PROTECT/UNPROTECT macro
to specify a virtual storage range that is within the read-only nucleus
that is backed by large pages.</li>
<li>Modify all applicable programs to no longer use the PGSER PROTECT/UNPROTECT
macro to specify the applicable virtual storage range.</li>
<li>If modification to the read-only nucleus is absolutely necessary,
use the DATOFF macro.</li></ol>
<p><strong>Reference information:</strong> <cite>z/OS MVS System Codes</cite> and <cite>z/OS MVS Programming: Assembler Services
Guide</cite>.</p>
<h4 id="warnund">Consider exploiting WARNUND for new IEASYS<em>xx</em> statements</h4>
<p>[[[[ Contributing writer: Marna Walle/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Peter Relson/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>:  Starting in z/OS V1R13 (and rolled
back to z/OS V1R12 and z/OS V1R11 in OA35929), you can specify the
WARNUND statement in IEASYS<span class="synph"><span class="var">xx</span></span>.  When used,
this statement indicates that warning messages <span>IEA660I
and IEA321I</span> are to be issued when undefined statements are encountered,
rather than prompting for a correct statement.  Usage of WARNUND can
be particularly useful when specifying new parmlib options in IEASYS<span class="synph"><span class="var">xx</span></span> (such
as the new IXGCNF and CATALOG system parameters which are introduced
in z/OS V1R13), and <span>allowing these new IEASYS<span class="synph"><span class="var">xx</span></span> specifications
to be shared with pre-z/OS V2R1 systems.</span><a id="idx268"></a><a id="idx269"></a></p>
<table id="wq167" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13, and rolled back to z/OS V1R12 and
z/OS V1R11 with APAR OA35929.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12 without the PTF for
APAR OA35929 applied.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td> No, but recommended to assist in sharing
IEASYS<span class="synph"><span class="var">xx</span></span> members between z/OS V2R1, and
pre-z/OS V1R13 systems, when new enhancements in z/OS V2R1 are to
be exploited.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td> Ensure the PTF for APAR OA35929 is installed
on all pre-z/OS V1R13 systems so that the WARNUND statement can be
identified and processed correctly.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>Certain restrictions are identified when using
WARNUND in IEASYS<span class="synph"><span class="var">xx</span></span>.  See reference information
below.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Install the PTF for APAR OA35929 on all pre-z/OS V1R13
systems. z/OS V1R13 has the support incorporated.</li>
<li>As you add new statements in IEASYS<span class="synph"><span class="var">xx</span></span> for
functional exploitation and you wish to share those modified IEASYS<span class="synph"><span class="var">xx</span></span> members
with pre-z/OS V2R1 systems, add <strong>WARNUND</strong> to the beginning of
IEASYS00 as that will cover updates in all IEASYS<span class="synph"><span class="var">xx</span></span> members.</li></ol>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li><cite>z/OS MVS System Messages, Vol 6 (GOS-IEA)</cite>.</li>
<li><cite>z/OS MVS Initialization and Tuning Guide</cite>.</li>
<li>Documentation in the PTFs for APAR OA35929.</li></ul>
<h4 id="sodbcpii">Migrate from SNMP to z/OS BCPii for communication to the HMC
or SE for z/OS Capacity Provisioning support</h4>
<p>[[[[ Contributing writer: Wolf-Dieter
Hahn/Germany/IBM@IBMDE ]]]] [[[[ Technical contact: Michael Groetzner/Germany/IBM@IBMDE
]]]]</p>
<p><strong>Description</strong>: z/OS V1R13 is planned to be the last
release to provide the z/OS Capacity Provisioning support that utilizes
the System z API for communication with the Support Element (SE) or
Hardware Management Console (HMC). This protocol is based on IP network
connection using SNMP. IBM recommends configuring the Capacity Provisioning
Manager for communication via the z/OS BCP Internal Interface (BCPii)
protocol. The SE and HMC support for the System z API remains, and
is not affected by this withdrawal of support. If you are currently
using SNMP for the communication, it is recommended that you now migrate
to BCPii. The migration includes enabling the communication through
BCPii for the provisioning manager user and adding a new key to the
Capacity Provisioning Manager parameter file.</p>
<table id="wq169" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use Capacity Provisioning and you
have not yet migrated to BCPii.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ul>
<li>You can use the tracking facility to help with this migration
action. In tracking facility output, look for violations that start
with CPO-W:SNMP usage <span class="synph"><span class="var">domain name</span></span>, where <span class="synph"><span class="var">domain
name</span></span> is replaced with the actual name of the affected
domain. Exploit the z/OS tracking facility on z/OS V1R12 or z/OS
V1R11 by installing the PTF for APAR OA35284. If you are
using the tracking facility and have no instances of affected domains
after starting Capacity Provisioning Manager, then this migration
action is not applicable to you.</li>
<li>Set up BCPii as described in <cite>z/OS MVS Programming: Callable Services
for High-Level Languages</cite>.</li>
<li>Define the required security profiles to allow the Capacity Provisioning
Manager user to access the hardware information.</li>
<li>Add the Topology.Protocol=INTERNAL key to the Capacity Provisioning
Manager parameter file. Using the default values, the file is the
member CPO.DOMAIN1.PARM(PARM).</li></ul>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li>For information about BCPii setup, see <cite>z/OS MVS Programming: Callable Services
for High-Level Languages</cite>.</li>
<li>For information about required security profile and how to define
the new key to the Capacity Provisioning Manager parameters, see <cite>z/OS MVS Capacity Provisioning User&amp;apos;s
Guide</cite>.</li>
<li>For information about using the tracking facility, see
"Appendix A" <cite>z/OS MVS Planning: Operations</cite>.</li></ul>
<h3 id="e0z3m100-gen99">BCP actions to perform before the first IPL of z/OS V2R1</h3>
<p>This topic describes BCP migration actions that you can perform
after you have installed z/OS V2R1
but before the first time you IPL. These actions might require the z/OS V2R1 level of code to be installed
but do not require it to be active.</p>
<p><a href="e0z3m100.htm#aa3iplt">Create IPL text</a></p>
<p><a href="e0z3m100.htm#aa3sad">Reassemble the stand-alone dump program</a></p>
<p><a href="e0z3m100.htm#dt2mg295">Convert your existing IBM Health Checker for z/OS set-up for
automatic start-up</a></p>
<p><a href="e0z3m100.htm#dt2mg296">Plan for the increase of the maximum number of supported CPUs
to 256</a></p>
<p><a href="e0z3m100.htm#downgrade_sysdsn">Downgrade the SYSDSN ENQ control from exclusive to shared:
****** POSSIBLY REMOVED AS AN ACTION*********</a></p>
<p><a href="e0z3m100.htm#dt2mg297">Update automation that handles messages IEE302I, IEE303I, IEE1302I,
IEE1303I, and IOS566I ****** POSSIBLY REMOVED AS AN ACTION****************</a></p>
<p><a href="e0z3m100.htm#dt2mg298">Accommodate new address spaces on MAXUSER</a></p>
<p><a href="e0z3m100.htm#dt2mg556">Follow linkage conventions when you call z/OS Unicode Services</a></p>
<p><a href="e0z3m100.htm#esqa">Accommodate increase in ESQA</a></p>
<p><a href="e0z3m100.htm#nucleus">Accommodate increase in nucleus size</a></p>
<p><a href="e0z3m100.htm#dt2mg300">Review the list of WTORs in parmlib member AUTOR00</a></p>
<h4 id="aa3iplt">Create IPL text</h4>
<p><strong>Description</strong>: IPL text is bootstrap information
required for IPL (such as the location of the nucleus library).  You
must create IPL text by running ICKDSF against the system residence
volume.<a id="idx270"></a></p>
<table id="wq170" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Update and run the IPLTEXT
job to write a new copy of the IPL text. If you install z/OS with a ServerPac, an installation
dialog job is provided to perform this action. If you install z/OS with a CBPDO, instructions
to perform this action are provided in <cite>z/OS Program Directory</cite>.</p>
<p><strong>Tip</strong>:: With ICKDSF R17 APAR PM42057,
a new parameter called REMOVEIPLTXT has been added to the REFORMAT
command that allows you to remove IPL text from the volume.</p>
<div>
<div class="note-noindent" id="wq171">
<span class="notetitle">Note:</span> <span class="notebody">When the IPLTXTEXIST parameter (which was introduced
by ICKDSF R17 APAR PK16403) is specified with the REFORMAT command
using the IPLDD parameter, WTOR message ICK21836D is suppressed if
IPL text already exists.</span></div></div>
<p><strong>Reference information</strong>: For a sample IPLTEXT
job, see <cite>z/OS Program Directory</cite>. ServerPac provides a similar
job for accomplishing this task; see <cite>ServerPac: Installing Your Order</cite>.</p>
<h4 id="aa3sad">Reassemble the stand-alone dump program</h4>
<p><strong>Description</strong>: The stand-alone dump program produces a dump
of storage that is occupied by a system that failed or a stand-alone
dump program that failed. You must reassemble the stand-alone dump
program each release. Once the stand-alone dump program is properly
created on a DASD residence volume, it resides in the SYS1.PAGEDUMP.Vvolser
data set. <a id="idx271"></a><a id="idx272"></a><a id="idx273"></a><a id="idx274"></a></p>
<table id="wq172" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to
a specific release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Reassemble the stand-alone dump program.
If you install z/OS with a ServerPac, an installation dialog job is
provided to perform this action. If you install z/OS with a CBPDO,
instructions to perform this action are provided in <cite>z/OS MVS Diagnosis: Tools and Service Aids</cite>.</p>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li><cite>ServerPac: Installing Your Order</cite></li>
<li><cite>z/OS MVS Diagnosis: Tools and Service Aids</cite></li></ul>
<h4 id="dt2mg295">Convert your existing IBM Health Checker for z/OS set-up for
automatic start-up</h4><a id="idx275"></a>
<p></p>
<p><strong>Description</strong>: Before z/OS V2R1, IBM Health Care for z/OS
users had to perform a set-up procedure and start IBM Health Checker
for z/OS manually. Now the system starts IBM Health Checker for z/OS
automatically. 
</p>
<ul>
<li>For first time user of IBM Health Checker for z/OS, follow the
steps for Optimizing IBM Health Checker for z/OS in <cite>IBM Health Checker for z/OS: User's Guide</cite>.</li>
<li>For users with existing IBM Health Checker for z/OS set-ups, use
the migration action below to convert systems to the IBM Health Checker
for z/OS automatic start-up.</li></ul>
<table id="wq173" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but strongly recommended to take advantage
of IBM Health Checker for z/OS automatic start-up for installations
with an existing IBM Health Checker for z/OS set-up..</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ol type="1">
<li>Make sure the system knows the name of your hzsproc procedure
if you renamed it from the default HZSPROC: The start-up procedure
for IBM Health Checker for z/OS is called HZSPROC, by default. If
you customized your hzsproc name, you must specify it to the system,
using the new HZSPROC system parameter in IEASYSxx.</li>
<li>Remove any existing START HZSPROC invocations that start IBM
Health Checker for z/OS and rely on the automatic start-up: Because
IBM Health Checker for z/OS now starts automatically, you must look
for instances of START HZSPROC invocations in your installation. For
example, look for START HZSPROC invocations in the COMMANDxx, parmlib
member. 

<p>After the system brings IBM Health Checker for z/OS up
automatically, the system rejects any attempt to bring up a second
instance. The system issues message HZS0101I, stating that IBM Health
Checker for z/OS is already active.</p></li>
<li>Change the way you specify the HZSPRMxx parmlib members you
want the system to use: Before z/OS V2R1, users typically specified
the HZSPRMxx parmlib members for IBM Health Checker for z/OS in the
HZSPROC procedure. Now starting with z/OS V2R1, IBM recommends that
you do the following to tell the system which members of HZSPRMxx
to use:

<ol type="a">
<li>Specify the HZSPRMxx parmlib members for your installation in
the new HZS system parameter of IEASYSxx. This provides the default
for the automatic start of IBM Health Checker for z/OS at IPL-time.</li>
<li>In your hzsproc procedure, default to or define HZSPRM='PREV'://HZSPROC
 PROC HZSPRM='PREV'                                         
  //HZSSTEP  EXEC   PGM=HZSINIT,REGION=0K,TIME=NOLIMIT,          
         //      PARM='SET PARMLIB=&amp;HZSPRM'                  
                     //*HZSPDATA DD   DSN=SYS1.&amp;SYSNAME..HZSPDATA,DISP=OLD
                    //        PEND                               
                            //        EXEC HZSPROC    HZSPRM='PREV'
specifies the following:

<ul>
<li>For manual restarts after the initial automatic start, IBM Health
Checker for z/OS will use the same HZSPRMxx parmlib members as it
did for the previous instance of IBM Health Checker for z/OS.</li>
<li>For the initial automatic start, the system will use the HZSPRMxx
suffixes listed in the HZS system parameter.</li></ul>

<p>Specifying HZSPRM='PREV' makes occasional manual restarts
(after applying service, for example) easy and consistent.</p></li></ol></li>
<li>Optionally specify an HZSPDATA data set for persistent data
in the HZSPRMxx parmlib member: Before z/OS V2R1, you could only
specify the HZSPDATA in the HZSPROC startup procedure. Now you can
define your HZSPDATA data set in either the HZSPROC startup procedure or on
the HZSPDATA parameter of the HZSPRMxx parmlib member.</li></ol>
<p><strong>Reference information:</strong> 
</p>
<ul>
<li>For system parameters HZS and HZSPROC, see IEASYSxx (system parameter
list) in <cite>z/OS MVS Initialization and Tuning Guide</cite></li>
<li>For specifying the HZSPRMxx parmlib members you want the system
to use, see "Tell the system which members of HZSPRMxx you want to
use" in <cite>IBM Health Checker for z/OS: User's Guide</cite>.</li>
<li>For details on the HZSPROC procedure, see "The HZSPROC procedure"
in <cite>IBM Health Checker for z/OS: User's Guide</cite>.</li>
<li>For specifying the HZSPDATA data set for persistent data in HZSPRMxx,
see "Create HZSPRMxx parmlib members" in <cite>IBM Health Checker for z/OS: User's Guide</cite>.</li></ul>
<h4 id="loadxx">Consider the new default value for the LOADxx DYNCPADD keyword
that indicates how many CPUs z/OS is prepared to dynamically add</h4>
<p>[[[[ Marna Walle]]]]</p>
<p><strong>Description</strong>: Before z/OS V2R1, through PARMLIB member LOADxx
you could enable that CPUs be added to the configuration over the
life of the IPL if the hardware supported such addition. In z/OS V2R1,
the LOADxx keyword DYNCPADD now supports a 1-4 character decimal value
nnnn that indicates how many CPUs z/OS is able to dynamically add
over the life of the IPL. The default has changed to 16.</p>
<table id="wq176" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td> Yes, if the LOADxx DYNCPADD value
is omitted (defaulted) and the default number of CPUs (16) z/OS will
be able to dynamically add over the life of the IPL is not sufficient.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>All system z hardware (z10 EC/BC and later hardware)
that supports dynamic CPU addition.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>When specifying the maximum number
of CPs that z/OS can dynamically add with LOADxx DYNCPADD <span class="synph"><span class="var">nnnn</span></span>,
this LOADxx cannot be shared with pre-V2R1 systems; that is, the <span class="synph"><span class="var">nnnn</span></span> parameter
of DYNCPADD is not recognized by pre-V2R1 systems.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>Specifying DYNCPADD nnnn or taking the DYNCPADD
 16 default allows z/OS to determine the number of CPUs that z/OS
must be prepared to be dynamically added for the life of the IPL.
 Because z/OS can know the maximum CPU id that can be dynamically
added for the life of the IPL at IPL, z/OS can obtain CPU array related
storage based on the maximum number of CPUs that can be activated
for the life of the IPL.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ol type="1">
<li>If the default limit of 16 CPUs that can be dynamically added
is not sufficient, then indicate on your LOADxx DYNCPADD the number
you desire. The maximum number of CPUs that can be added over the
life of the IPL will be capped by the minimum between the highest
CPU id hardware and the z/OS release supports.</li>
<li>Review the changed messages associated with two digit CP IDs.
Update any necessary automation or operator procedures to accommodate
the two digits. Before z/OS V2R1, there was only one digit used for
CP IDs. The messages that will now contain 2 byte CP ids are the following:
 

<ul>
<li>BLW007W MULTIPLE ACR ATTEMPTS BY CPU id</li>
<li>IEA020W AN FRR STACK POINTER FOR CPU xxxx IS DAMAGED, THE ERROR
MASK IS abcdefghijklmnopqrst</li>
<li>IEA796E ACR HAS TAKEN CPU x [LOGICALLY] OFFLINE BECAUSE <span class="synph"><span class="var">text</span></span> 

<p><span class="synph"><span class="var">text</span></span> inserts
that are updated include:  
</p>
<ul>
<li>CPU <span class="synph"><span class="var">x</span></span> CHECKSTOPPED.</li>
<li>CPU <span class="synph"><span class="var">x</span></span> REACHED ITS <span class="synph"><span class="var">vv</span></span> MACHINE-CHECK
THRESHOLD.</li>
<li>CPU <span class="synph"><span class="var">x</span></span>'S TOD CLOCK COULD NOT BE SYNCHRONIZED.</li>
<li>CPU <span class="synph"><span class="var">x</span></span>'S CLOCK COULD NOT BE SYNCHRONIZED
TO THE ETR</li></ul></li>
<li>IEE178I AUTOMATIC RECOVERY IS IN PROGRESS. NO OPERATOR ACTION
IS REQUIRED. 

<ul>
<li>[PROCESSOR (<span class="synph"><span class="var">y</span></span>) DETECTED AN EXCESSIVE
DISABLED SPIN LOOP WAITING FOR event FROM PROCESSOR (<span class="synph"><span class="var">x</span></span>)]</li>
<li>[An event OCCURRED WHEN PROCESSOR (y) TRIED TO SIGNAL PROCESSOR
(<span class="synph"><span class="var">x</span></span>)]</li></ul></li>
<li>IEE331A PROCESSOR (<span class="synph"><span class="var">y</span></span>) IS IN AN EXCESSIVE
DISABLED SPIN LOOP WAITING FOR <span class="synph"><span class="var">event</span></span>. REPLY
U OR SPIN TO CONTINUE SPIN, REPLY ABEND TO TERMINATE WORK ON PROCESSOR
(<span class="synph"><span class="var">x</span></span>) WITH RETRY REPLY TERM TO TERMINATE WORK
ON PROCESSOR (<span class="synph"><span class="var">x</span></span>) WITHOUT RETRY OR STOP PROCESSOR
(<span class="synph"><span class="var">x</span></span>) AND REPLY ACR</li>
<li>ISN011I CPU nnnn HAS BEEN ADDED</li></ul></li></ol>
<p><strong>Reference information</strong>: <cite>z/OS MVS Initialization and Tuning Reference</cite>.</p>
<h4 id="dt2mg296">Plan for the increase of the maximum number of supported CPUs
to 256</h4><a id="idx276"></a>
<p><strong>Description</strong>: In z/OS V2R1, z/OS CPU infrastructure will
support up to a maximum of 256 CPUs (CPU ids 0-255). Earlier releases
of z/OS support up to 100 CPUs (CPU ids 0-99). Components or products
allocating storage for CPU related arrays or bitmasks might require
changes to support the V2R1 CPU infrastructure.</p>
<p>Allocating CPU related arrays or bitmasks on a per CPU basis is
done using one of the following: 
</p>
<ul>
<li>Run-time fields in the z/OS CVT (mapped by CVT) and ECVT (mapped
by IHAECVT) control blocks representing the maximum CPU id a z/OS
image can use for the life of the IPL. Products using run time fields
will not require changes to support the V2R1 CPU infrastructure.</li>
<li>Compile-time or assemble-time constants in the z/OS ECVT control
block or within the product itself representing the maximum CPU id
the z/OS CPU infrastructure supports. Products using compile-time
or assemble-time constants will need to recompile at a minimum and
may require code changes to support the V2R1 CPU infrastructure.</li></ul><p class="indatacontent">All products running on z/OS V2R1 must prepare to support all
CPUs supported by the z/OS V2R1 CPU infrastructure (up to 256 CPUs
with CPU ids 0-255). Products that support the z/OS V2R1 CPU infrastructure
will be able to run on earlier z/OS releases whose CPU infrastructure
supports a fewer number of CPUs.</p>
<table id="wq178" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
the first IPL of z/OS V2R1</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, for for programs using local constants
or the z/OS constants for the number of CPUs the z/OS CPU infrastructure
supports at the current or a specific level of z/OS</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>Programs that do not support up to the maximum
number of CPUs the z/OS infrastructure supports might not be able
to work with all CPUs on the z/OS image. The system impacts are program
dependent.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ul>
<li>Scan your code for all of the constants in the ECVT control block
below that have a prefix of ECVT_max_* or ECVT_zOSR11_*. These fields
are all related to the maximum CPU id the current or a specific z/OS
release supports.</li>
<li>Scan your code for compile-time or assemble-time constants in
your product for constants related to the maximum CPU id that the
current or a specific z/OS release supports. Also scan your product
for constants related to the maximum number of CPUs the current or
a specific z/OS release supports.</li></ul>
<p>If you use ECVT constants with a prefix of ECVT_max_* or ECVT_zOSR11_*
, the product will require the following changes:
</p>
<ul>
<li>If the ECVT_zOSR11_highestCPUID or ECVT_max_highestCPUID constants
are in use:, consider upgrading your code to use the run-time field
CVTMAXMP (for allocating CPU related arrays) or ECVT_Installed_CPU_HWM
(for traversing CPU related arrays). &bull;</li>
<li>If ECVT compile-time or assemble-time constants with a prefix
of ECVT_max_* are in use, recompile/reassemble all appropriate parts
with the new z/OS V2R1 IHAECVT macro.</li>
<li>If ECVT compile-time or assemble-time constants with a prefix
of ECVT_zOSR11_* are in use, consider converting constants with a
prefix of ECVT_zOSR11_* to the ECVT_max_* analog. Otherwise change
ECVT_zOSR11_* to the new ECVT_zOSV2R1 analog.</li></ul><p class="indatacontent"> If your code has its own local declares for compile-time or
assembler-time constants, update your code to use the z/OS run-time
fields or the z/OS compile-time or assemble-time constants. To do
this, see ICN Request Greater Than 64 CPUs 10-22-07????? and do the
following:
</p>
<ol type="1">
<li>Allocate CPU bit masks at compile-time or assemble-time using
ECVT_max_CPUMaskSizeInBits or ECVT_max_CPUMaskSizeInBytes.</li>
<li>Convert to using run-time fields like CVTMAXMP to allocate your
local CPU related arrays. If using run-time fields is undesirable,
allocate CPU arrays using the compile-time or assemble time constants
ECVT_max_* or ECVT_zOSV2R1_* fields</li></ol>
<p><strong>Reference information:</strong> 
NEED A REFERENCE.</p>
<h4 id="downgrade_sysdsn">Downgrade the SYSDSN ENQ control from exclusive to shared:
****** POSSIBLY REMOVED AS AN ACTION*********</h4><a id="idx277"></a><a id="idx278"></a><a id="idx279"></a><a id="idx280"></a><a id="idx281"></a><a id="idx282"></a>
<p>[[[[ Contributing writer: Debra A Quick/Somers/IBM@IBMUS
]]]] [[[[ Technical contact: Brian Keuling/Poughkeepsie/IBM]]]]</p>
<p> eReview discussion from first review suggests removing
this action.</p>
<p></p>
<div>
<div class="note-noindent" id="wq180">
<span class="notetitle">Note:</span> <span class="notebody">This action will be finalized in the 3rd draft review of
Migration V2R1.</span></div></div>
<p><strong>Description</strong>: Before z/OS V2R1, the SYSDSN ENQ was exclusive.
Starting with z/OS V2R1, the SYSDSN ENQ control can be changed from
exclusive to shared. This change can affect the function by allowing
better parallelism of batch execution when multiple jobs need to share
a data set resource. The downgrading of control level has potential
to speed up batch processing; however it can expose problems in user
JCL.<a id="idx283"></a></p>
<table id="wq181" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Optional, if the user decides to downgrade the
SYSDSN ENQ control.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Determine if the JCL can accommodate having
its SYSDSN ENQ downgraded. If the data set is being modified after
its last exclusive usage requesting step, then the new function will
be problematic for that particular job. Therefore, it should not be
requesting through the JES jobclass attribute/JCL keyword to enable
the new function.</p>
<p><strong>Reference information</strong>: For details about downgrading the
SYSDSN ENQ control from exclusive to shared, see .</p>
<h4 id="dt2mg297">Update automation that handles messages IEE302I, IEE303I, IEE1302I,
IEE1303I, and IOS566I ****** POSSIBLY REMOVED AS AN ACTION****************</h4><a id="idx284"></a>
<p>[[[[ Contributing writer: Rita M Beisel/Poughkeepsie/IBM
]]]] [[[[ Technical contact: Ilene Goldman/Poughkeepsie/IBM ]]]]</p>
<p><strong>Description</strong>: Starting in z/OS V2R1, the following messages
have changed message text:
</p>
<ul>
<li>Messages IEE302I, IEE303I, IEE1302I, and IEE1303I are changed
from including ESCM in the message text to including CONFIG MANAGER
in the message text.</li>
<li>Message IOS566I is changed from including SYSTEM AUTOMATION in
the message text to including CONFIG MANAGER in the message text.</li></ul>
<p>If you use automation programs to handle messages, or you have
operator or other procedures that deal with messages, you should update
the programs or procedures appropriately.</p>
<table id="wq182" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use automation programs or other
procedures to handle messages IEE302I, IEE303I, IEE1302I, IEE1303I,
and IOS566I.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Modify automated actions for IEE302I, IEE303I,
IEE1302I, IEE1303I, and IOS566I so they now work with the updated
message text.</p>
<p><strong>Reference information:</strong> For details about messages IEE302I,
IEE303I, IEE1302I, and IEE1303I, see <cite>z/OS MVS
System Messages, Volume 7 (IEB-IEE)</cite>. For details about messages
IOS566I, see <cite>z/OS MVS System Messages, Volume
9 (IGF-IWM)</cite>.</p>
<h4 id="dt2mg298">Accommodate new address spaces on MAXUSER</h4><a id="idx285"></a><a id="idx286"></a><a id="idx287"></a>
<p>[[[[ Contributing writer: Rita M Beisel/Poughkeepsie/IBM
]]]] [[[[ Technical contact: Ken Yee/Poughkeepsie/IBM and Dale Riedy/Poughkeepsie/IBM]]]]</p>
<p><strong>Description</strong>: The MAXUSER value in parmlib member IEASYS<em>xx</em> specifies
a value that the system uses to limit the number of jobs and started
tasks that can run concurrently during a given IPL. Increase your
MAXUSER value to take new address spaces into account.</p>
<p>There are two new address spaces in z/OS V2R1 called PCIE (PCI
Express) and FPGHWAM (Hardware Accelerator Manager). They provide
the infrastructure for PCI Express I/O and hardware accelerator activities.</p>
<p>These address spaces are started automatically during z/OS initialization,
if the appropriate z/OS PCIE facilities hardware is installed. They
are persistent address spaces.</p>
<p>If the PCIE address space is successfully initialized, message
IQP002I PCIE INITIALIZATION COMPLETE is displayed.</p>
<p>If the required hardware is not installed, message IQP031I REQUESTED
SERVICE IS UNSUPPORTED BY HARDWARE is written to the hardcopy log.</p>
<table id="wq183" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to ensure that your MAXUSER
value in parmlib member IEASYSxx is adequate.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If necessary, increase your MAXUSER value
in parmlib member IEASYS<em>xx</em> to take the new address
spaces into account. One way to find out how many address spaces you
use is to issue the DISPLAY A,L command and total the address spaces
in the IEE114I and IEE115I messages on the old and new systems.</p>
<p>Notes:
</p>
<ol type="1">
<li>A modest overspecification of MAXUSER should not hurt system performance.</li>
<li>The number of total address spaces is the sum of M/S, TS USERS,
SYSAS, and INITS.</li>
<li>If you change your MAXUSER value, you must re-IPL to make the
change effective.</li></ol>
<p><strong>Reference information:</strong> For information about the MAXUSER
parameter, including its interaction with the RSVSTRT and RSVNONR
parameters and factors that contribute to the number of active address
spaces, see <cite>z/OS MVS Initialization and Tuning
Reference (IGF-IWM)</cite>.</p>
<p>For information about the hardware accelerator-related messages,
see <cite>z/OS MVS System Messages, Volume 5 (EDG-GFS)</cite>.</p>
<p>For information about the PCIE messages, see <cite>z/OS
MVS System Messages, Volume 9 (IGF-IWM)</cite>.</p>
<h4 id="dt2mg299">Follow linkage conventions when you call z/OS Unicode Services</h4><a id="idx288"></a><a id="idx289"></a>
<p>[[[[ Contributing writer: Rita M Beisel/Poughkeepsie/IBM
]]]] [[[[ Technical contact: Pat Glenski/Rochester/IBM ]]]]</p>
<p><strong>Description</strong>: Starting in z/OS V1R13, z/OS Unicode Services
enforces the linkage conventions documented in <cite>z/OS
Unicode Services User's Guide and Reference</cite>. The z/OS Unicode
Services interfaces follow the MVS linkage conventions described in
'Linkage Conventions' in <cite>z/OS MVS Programming:
Assembler Services Guide</cite>.</p>
<table id="wq185" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are using z/OS Unicode Services.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Verify that when you call the z/OS Unicode
Services interfaces, you follow the linkage conventions. Specific
details about the conventions that are enforced are included in the
documentation of each z/OS Unicode Services interface. In general,
the linkage conventions are:
</p>
<ul>
<li>GPR 1 - Caller must set to the address of the parameter area.</li>
<li>GPR 13 - Caller must set to the address of a save area.</li>
<li>GPR 14 - Caller must set to the return address.</li>
<li>GPR 15 - Caller must set to the entry address. The stub routines
do this automatically.</li></ul>
<p><strong>Reference information:</strong> For more information about these
linkage conventions, see the section on 'Linkage conventions' in<cite>z/OS Unicode Services User's Guide and Reference</cite>.
For more information about the MVS linkage conventions, see <cite>z/OS MVS Programming: Assembler Services Guide</cite>.</p>
<h4 id="nucleus">Accommodate increase in nucleus size</h4>
<p>[[[[ Contributing writer: &lt;Example,
Jim Guilinrelli/Poughkeepsie/IBM@IBMUS &gt; ]]]] [[[[ Technical contact: &lt;Marna
Walle/Poughkeepsie/IBM@IBMUS &gt; ]]]]</p>
<p><strong>Description</strong>: With the introduction of the z/OS V1R13 RSM Enablement Offering Web deliverable,
the nucleus will increase in size by approximately 380K above the
16MB line. Because of this increase, the available private storage
might affect the way your applications run on your system.<a id="idx290"></a></p>
<table id="wq186" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13
RSM Enablement Offering Web deliverable.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13
without the z/OS V1R13 RSM
Enablement Offering Web deliverable or from z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the increase in nucleus size will affect
the private storage available to applications on your system above
the 16MB line.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None. The migration action is relevant on all
servers.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>Failure to have sufficient private storage available
might result in errors that affect the running of your applications.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td> VSM_CSA_CHANGE. You can use this health check
to identify changes in the size of CSA or private (including the extended
areas) since the last IPL.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Review your current available private storage
usage above the 16MB line using reports from RMF or an equivalent product. Ensure that an
increase of 380K for the nucleus above the 16 MB line will not adversely
affect your system. Adjust values accordingly.</p>
<p><strong>Reference information</strong>: See <a href="e0z3m100.htm#at3limi">Verify that virtual storage limits are set properly</a></p>
<p>Also see <cite>z/OS MVS Initialization and Tuning Guide</cite> and <cite>z/OS MVS Initialization and Tuning Reference</cite>.</p>
<h4 id="esqa">Accommodate increase in ESQA</h4>
<p>[[[[ Contributing writer: &lt;Example,
Jodi E Everdon/Poughkeepsie/IBM@IBMUS &gt; ]]]] [[[[ Technical contact: &lt;Example:
Karla Arndt/Rochester/IBM@IBMUS &gt; ]]]]</p>
<p><strong>Description</strong>: With the introduction of the z/OS V1R13 RSM Enablement Offering
Web deliverable, there is an increase of 24K (6 pages) in ESQA per
CPU per LPAR. This increase in ESQA per CPU includes general purpose
CPs, zIIPs, and zAAPs regardless of the status (online, offline, configured,
stand-by, and so forth) of the hardware. Because of this increase,
the available private storage may affect application execution on
your system.</p>
<table id="wq187" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx291"></a><a id="idx292"></a><a id="idx293"></a><strong>Element or
feature</strong>:</td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13
RSM Enablement Offering Web deliverable.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13
without the z/OS V1R13 RSM
Enablement Offering Web deliverable or from z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the increase in ESQA will affect the
private storage available to applications on your system.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>The migration action is relevant on all servers.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>Failure to have sufficient private storage available
might result in errors that affect the running of your applications.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>VSM_CSA_CHANGE. You can use this health check
to identify changes in the size of CSA or private (including the extended
areas) since the last IPL.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Review your current available private storage
usage above the 16 MB line using reports from RMF or an equivalent product. Ensure that an
ESQA increase of 24K per CPU used on the LPAR will not adversely affect
your system. Adjust values  accordingly.</p>
<p><strong>Reference information</strong>: See <a href="e0z3m100.htm#at3limi">Verify that virtual storage limits are set properly</a></p>
<p>Also see <cite>z/OS MVS Initialization and Tuning Guide</cite> and<cite>z/OS MVS Initialization and Tuning Reference</cite>.</p>
<h4 id="dt2mg300">Review the list of WTORs in parmlib member AUTOR00</h4><a id="idx294"></a>
<p>[[[[ Contributing writer: Jing Die Huang/China/IBM@IBMCN
]]]] [[[[ Technical contact: Richard Bibolet/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: In z/OS V1R12, the DDDEF"d
PARMLIB provides an AUTOR00 member. This member should be found in
your parmlib concatenation during IPL and will result in auto-reply
processing being activated. If the WTORs listed in AUTOR00 are automated
by your existing automation product, ensure that the replies in AUTOR00
are appropriate.</p>
<table id="wq188" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td align="left">BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td align="left">z/OS V1R12. General migration
action.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td align="left">z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td align="left">Before the first IPL of z/OS
V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td align="left">Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td align="left">None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td align="left">None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td align="left">None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td align="left">None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td align="left">None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td align="left">None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Examine the WTOR replies in the AUTOR00 parmlib
member. If the replies or delay duration are not desirable, you can
create a new AUTORxx parmlib member and make corresponding changes.
Also compare the replies to what your automation product would reply
to these WTORs. Make sure that the AUTOR00 replies are in accordance
with the replies from your automation product. IBM does not recommend
making updates to AUTOR00, because updates to AUTOR00 might be made
by the service stream or in new z/OS releases.</p>
<div>
<div class="note-noindent" id="wq189">
<span class="notetitle">Note:</span> <span class="notebody">
<ul>
<li>If you have created an AUTORxx parmlib member, update the IEASYSyy
parmlib member that you use for IPL. Add the following statement to
the IEASYSyy member:  
<pre class="xmp"><code>AUTOR=(xx,00)</code></pre>Here xx
corresponds to the AUTORxx parmlib member that you created.  The IEASYSyy
members specifying AUTOR cannot be shared with prior z/OS releases.
If you only need the default AUTOR00 settings, you can omit specifying
AUTOR= in IEASYSyy, and other z/OS levels can continue to use IEASYSyy.
Even if AUTOR= is not specified in IEASYSyy, AUTOR00 is used if it
exists. If you have automation already in place for a WTOR and that
WTOR now appears in AUTOR, the AUTOR version still can be used. Review
the WTORs in AUTOR and your automation; either remove the WTOR from
AUTOR or from your automation.</li>
<li>If you don't want to activate auto-reply processing, specify AUTOR=OFF
in the parmlib member IEASYSxx or in response to message IEA101A SPECIFY
SYSTEM PARAMETERS. It is not recommended that you remove AUTOR00 from
parmlib, because service or new releases might reinstall AUTOR00.
If there is no AUTOR00 member in parmlib, auto-reply is not activated
and the following messages are produced:
<pre class="xmp"><code>CNZ2600I AUTO-REPLY POLICY ATTEMPTING TO USE AUTOR=00.          
IEA301I AUTOR00 NOT FOUND IN PARMLIB                               
CNZ2601I AUTO-REPLY POLICY NOT ACTIVATED. 
NO ENTRIES SPECIFIED</code></pre></li>
<li>The IEASYSyy members specifying AUTOR=OFF cannot
be shared with earlier z/OS releases.</li></ul></span></div></div>
<p><strong>Reference information:</strong> For more information about the AUTORxx
and IEASYSyy parmlib members, see <cite>z/OS MVS Initialization and Tuning Reference</cite>.</p>
<h3 id="e0z3m100-gen100">BCP actions to perform after the first IPL of z/OS V2R1</h3>
<p>This topic describes BCP migration actions that you can perform
only after you have IPLed z/OS V2R1.
You need a running z/OS V2R1
system to perform these actions.</p>
<p><a href="e0z3m100.htm#dt2mg304">Do not disable TRACKDIRLOAD</a></p>
<p><a href="e0z3m100.htm#li2657d">Accommodate the SETLOAD IEASYM command to update system symbols
without initiating an IPL</a></p>
<p><a href="e0z3m100.htm#cpccdef">Plan for  discontinuation of enhancements to the Windows-based
Capacity Provisioning Control Center (CPCC) for use with z/OS MVS
Capacity Provisioning</a></p>
<h4 id="dt2mg304">Do not disable TRACKDIRLOAD</h4><a id="idx295"></a>
<p></p>
<p><strong>Description</strong>: TBD</p>
<table id="wq190" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td></td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After
the first IPL of V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td></td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<p><strong>Reference information:</strong></p>
<h4 id="li2657d">Accommodate the SETLOAD IEASYM command to update system symbols
without initiating an IPL</h4><a id="idx296"></a><a id="idx297"></a><a id="idx298"></a><a id="idx299"></a><a id="idx300"></a>
<p><strong>Description</strong>: Before z/OS V2R1, the downloadable
SYMUPDTE routine and the IEASYMUP module in SAMPLIB were provided
as mechanisms to update system symbols without initiating an IPL.
Starting with z/OS V2R1, the SETLOAD xx,IEASYM command is available
to perform this task. In z/OS V2R1, the <span>IEASYMUP</span> module
in SAMPLIB is updated to return with a RC=999, not having done the
requested function. However, unless this IEASYM module is rebound,
there is no way to prevent the usage of an old copy, or detect an
update due to use of an old copy of the tool.<a id="idx301"></a></p>
<table id="wq191" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are currently using the IEASYM module
provided in SAMPLIB or the SYMUPDTE routine to update system symbols.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>If you continue to use an obsolete method (SYMUPDTE
routine or the IEASYMUP module) , the system will continue to function
properly until the SETLOAD xx,IEASYM command is used, at which point
updates introduced by those other programs will be lost.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>SUP_SYSTEM_SYMBOL_TABLE_SIZE. This code checks
if the size of the static system symbol table has exceeded the threshold.
This check is initially run once and is also run when the SETLOAD
xx.IEASYM command is successfully processed.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Rebind the IEASYMUP module from
the z/OS V2R1 SAMPLIB to disable the code or simply remove it from
LINKLIB or your LNKLST library. If you have used the SYMUPDTE downloadable
module, remove it from your LINKLIB or your LNKLST library.
Begin using SETLOAD xx,IEASYM command instead of these obsolete modules.</p>
<p><strong>Reference information</strong>: The "SETLOAD command" in <cite>z/OS MVS System Commands</cite> and
"System Symbols" in <cite>z/OS MVS Initialization and Tuning Reference</cite></p>
<p>For information on the
IEASYMUP module or the SYMUPDTE routine, see <em>z/OS Planned Outage
Avoidance Checklist</em> at the IBM Redbooks site:
</p>
<ul>
<li>
<p><a href="http://www.ibm.com/support/us/en/?lnk=msd-0-usen" target="_blank">Support &amp;
downloads</a></p></li></ul><p class="indatacontent"> the Redbooks site at <a href=" http://www.ibm.com/redbooks">http://www.redbooks.ibm.com/abstracts/sg247328.html?Open</a>.</p>
<h4 id="cpccdef">Plan for  discontinuation of enhancements to the Windows-based
Capacity Provisioning Control Center (CPCC) for use with z/OS MVS
Capacity Provisioning</h4>
<p>[[[[ Contributing writer: Wolf-Dieter
Hahn/Germany/IBM@IBMDE ]]]] [[[[ Technical contact: Michael Groetzner/Germany/IBM@IBMDE
]]]]</p>
<p><strong>Description</strong>: /OS V1R13 is the last release to provide enhancements
to the Windows-based Capacity Provisioning Control Center (CPCC) function
for use with z/OS MVS Capacity Provisioning. As of z/OS V2R1, IBM
provides an alternative means to define Capacity Provisioning polices
and to add function to the z/OSMF-based Capacity Provisioning application
to allow you to control your Capacity Provisioning function.<a id="idx302"></a><a id="idx303"></a></p>
<table id="wq192" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1?</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to continue using your existing
CPCC workspace.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>????</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Move to the function for CPPC provided by
z/OS V2R1??????????</p>
<p><strong>Reference information</strong>: For more information about installing
and uninstalling CPCC, see <cite>z/OS MVS Capacity Provisioning User&amp;apos;s
Guide</cite>.</p>
<h2 id="bookmanagerbuild">BookManager BUILD migration actions</h2>
<p>This topic describes migration actions for optional feature BookManager
BUILD.</p>
<h3 id="bookmanagerbinstall">BookManager BUILD actions to perform before installing z/OS
V2R1</h3><a id="idx304"></a>
<p>This topic describes BookManager BUILD migration actions that you
can perform on your current (old) system. You do not need the z/OS
V2R1 level of code to make these changes, and the changes do not require
the z/OS V2R1 level of code to run once they are made.</p>
<p><a href="e0z3m100.htm#bookmanagersod">Plan for the removal of support for the optional feature BookManager
BUILD</a></p>
<h4 id="bookmanagersod">Plan for the removal of support for the optional feature BookManager
BUILD</h4><a id="idx305"></a>
<p></p>
<p><strong>Description</strong>: z/OS
V2R1 is the last release that is planned to support the optional feature
BookManager BUILD of z/OS. Plan for the removal of support.</p>
<table id="wq193" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BookManager
BUILD</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes,
if you use the optional feature BookManager BUILD.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<p>Remove support of BookManager BUILD for releases of z/OS later
than z/OS V2R1.</p>
<p><strong>Reference information:</strong> 
See Statement of Direction????????</p>
<h3 id="bookmbeforeipl">BookManager BUILD actions to perform before the first IPL of
z/OS V2R1</h3>
<p>This topic describes BookManager BUILD migration actions that you
can perform after you have installed z/OS V2R1 but before the first
time you IPL. These actions might require the z/OS V2R1 level of code to be installed but
do not require it to be active.</p>
<p>None.</p>
<h3 id="bookmbafteripl">BookManager BUILD actions to perform after the first IPL of
z/OS V1R13</h3>
<p>This topic describes BookManager BUILD migration actions that you
can perform only after you have IPLed z/OS V2R1. You need a running
z/OS V2R1 system to perform these actions.</p>
<p>None.</p>
<h2 id="ad1coms">Communications Server migration actions</h2>
<p>This topic describes migration actions for base element Communications
Server.</p>
<h3 id="e0z3m100-gen101">Communications Server actions to perform before installing
z/OS V2R1</h3><a id="idx306"></a>
<p>This topic describes Communications Server migration actions that
you can perform on your current (old) system. You do not need the z/OS V2R1 level of code to make
these changes, and the changes do not require the z/OS V2R1 level of code to run once they are
made.</p>
<p><a href="e0z3m100.htm#conass">Configuration assistant: Migrate to the Configuration Assistant
for Communications Server in the z/OS Management Facility (z/OSMF)</a></p>
<p><a href="e0z3m100.htm#dt2mg326">IP Services: Ensure FTP is listed in the AUTHCMD and AUTHPGM
NAMES section of your IKJTSOxx member of SYS1.PARMLIB</a></p>
<p><a href="e0z3m100.htm#dvipsec">IP Services: Understand the change in the support provided
by the DVIPSEC parameter on the IPSEC statement in the TCP/IP profile</a></p>
<p><a href="e0z3m100.htm#ipfrag">IP Services: Be aware of IP Fragment attack type of the Intrusion
Detection Services (IDS) enhancements to monitor both IPv4 and IPv6
traffic</a></p>
<p><a href="e0z3m100.htm#dt2mg327">IP Services: Plan for the change of greater than 8 characters
for the FTP password</a></p>
<p><a href="e0z3m100.htm#dt2mg328">IP Services: Relink NMI applications using the 64-bit TMI copy
buffer function (EZBTMIC4)</a></p>
<p><a href="e0z3m100.htm#dt2mg329">IP Services: Review C/C++ applications that use the GetProfile
request of the TCP/IP callable network management interface (NMI)</a></p>
<p><a href="e0z3m100.htm#preparefortheadditionofipv6supportforpolicy-basedrouting">IP Services: Prepare for the addition of IPv6 support for policy-based
routing</a></p>
<p><a href="e0z3m100.htm#dt2mg330">IP Services: Replace any GATEWAY statements in the TCP/IP profile
 with equivalent  BEGINROUTES statements</a></p>
<p><a href="e0z3m100.htm#bind2">IP Services: Migrate from BIND 9.2.0</a></p>
<h4 id="conass">Configuration assistant: Migrate to the Configuration Assistant
for Communications Server in the z/OS Management Facility (z/OSMF)</h4><a id="idx307"></a><a id="idx308"></a><a id="idx309"></a>
<p>Starting in z/OS V2R1, IBM Configuration Assistant for z/OS Communications
Server is no longer offered as a stand-alone application that runs
on the Windows operating system. IBM Configuration Assistant for z/OS
Communications Server is available as a fully supported task in the
z/OSMF product. Use the task available in z/OSMF.</p>
<table id="wq194" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if a Windows desktop version is being used.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<p>To use the IBM Configuration Assistant for z/OS Communications
Server task, you need to take the following steps:</p>
<ol type="1">
<li>Configure z/OSMF.</li>
<li>Transfer your existing backing store files into the z/OSMF environment
if desired.</li></ol>
<p><strong>Reference information</strong>: 
</p>
<ul>
<li>For information about configuring z/OSMF, see <cite>IBM z/OS Management Facility Configuration Guide</cite>.</li>
<li>For information about transferring Configuration Assistant backing
store files to z/OSMF, see the Updating z/OS for the Configuration
Assistant plug-in section in <cite>IBM z/OS Management Facility Configuration Guide</cite>.</li>
<li>For a complete list of all the z/OS Communications Server
commands and programs that need to be added to the AUTHCMD NAMES and
AUTHPGM NAMES statements in your IKJTSOxx PARMLIB member, see the <cite>z/OS Program Directory</cite> .</li></ul>
<h4 id="dt2mg326">IP Services: Ensure FTP is listed in the AUTHCMD and AUTHPGM
NAMES section of your IKJTSOxx member of SYS1.PARMLIB</h4><a id="idx310"></a>
<p></p>
<p><strong>Description</strong>: Beginning
in z/OS V2R1, the z/OS FTP client supports user exits. The FTP client
invokes z/OS Dynamic Exit Services (DES) to determine whether you
have installed FTP client user exit EZAFCCMD or EZAFCREP.  To invoke
DES successfully, the program FTP must be APF authorized. Therefore,
you must add  FTP to the AUTHCMD and AUTHPGM NAMES section of your
IKJTSOxx member of SYS1.PARMLIB.  Otherwise, the following error messages
EZA1555I are displayed when you start the FTP client:
</p>
<ul>
<li>CSVDYNEX DEFINE failed for user exit EZAFCCMD, RETURN CODE x'08'
REASON CODE x'00000804'</li>
<li>CSVDYNEX DEFINE failed for user exit EZAFCREP, RETURN CODE x'08'
REASON CODE x'00000804'</li></ul>
<table id="wq196" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td width="49%"><strong>Element or feature:</strong></td>
<td width="50%">Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes,
if you invoke the z/OS FTP client.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Add
FTP in the AUTHCMD and AUTHPGM NAMES section of your IKJTSOxx member
of SYS1.PARMLIB.</p>
<div>
<div class="note-noindent" id="wq197">
<span class="notetitle">Note:</span> <span class="notebody">In z/OS V2R1, SYS1.SAMPLIB(IKJTSO00) member contains
the FTP definitions in both AUTHCMD and AUTHPGM NAMES section.</span></div></div>
<p><strong>Reference information:</strong> 
</p>
<ul>
<li>FTP client user exits in <cite>z/OS Communications Server: IP Configuration Reference</cite>.</li>
<li>TSO command authorization in <cite>z/OS Communications Server: IP Configuration Guide</cite>..</li></ul>
<h4 id="dvipsec">IP Services: Understand the change in the support provided
by the DVIPSEC parameter on the IPSEC statement in the TCP/IP profile</h4>
<p>[[[[ Contributing writer: Jie Z Zhu/China/IBM]]]]
[[[[ Technical contact: Brad Crater, Charles Cruse/Raleigh/IBM, Alan
Packett/Raleigh/IBM, Joyce Anne Porter/Raleigh/IBM&gt; ]]]]</p>
<p><strong>Description</strong>: Before z/OS V2R1, the DVIPSEC parameter on
the IPSEC statement in the TCP/IP profile enabled Sysplex-Wide Security
Associations (SWSA) for IPv4 on a stack that had IPCONFIG IPSECURITY
specified in the TCP/IP profile.  Support for SWSA for IPv6 was not
provided in these releases.</p>
<p>Beginning with z/OS V2R1, SWSA for IPv6 is supported.  The DVIPSEC
parameter on the IPSEC statement in the TCP/IP profile enables SWSA
for IPv6 on a stack that has IPCONFIG6 IPSECURITY specified in the
TCP/IP profile.</p>
<table id="wq198" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx311"></a><a id="idx312"></a><a id="idx313"></a><strong>Element
or feature</strong>:</td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the TCP/IP profile for your stack specifies
the IPSECURITY parameter on the IPCONFIG6 statement and also specifies
the DVIPSEC parameter on the IPSEC statement.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ul>
<li>If you have both of the following specified in your TCP/IP
profile, be aware that SWSA for IPv6 will be enabled on your stack: 

<ul>
<li>The IPSECURITY parameter on the IPCONFIG6 statement</li>
<li>The DVIPSEC parameter on the IPSEC statement</li></ul></li>
<li>If you have IPv6 TCP traffic that is protected by an IPSec Security
Association (SA) with an IPv6 DVIPA endpoint, you can see the following
changes: 

<ul>
<li>When an IPv6 DVIPA is moved during a planned or unplanned DVIPA
takeover, new SAs are automatically reestablished with the same security
service characteristics as the SAs that existed on the host that owned
the DVIPA.</li>
<li>IPv6 TCP traffic that is protected by an IPSec SA with a sysplex-distributed
DVIPA endpoint can be distributed to target hosts.</li></ul></li>
<li>Ensure that you configure the appropriate IP security policy on
the backup and target hosts.</li></ul>
<p><strong>Reference information</strong>: See "Sysplex-Wide Security Associations"
in <cite>z/OS Communications Server: IP Configuration Guide</cite>.</p>
<h4 id="ipfrag">IP Services: Be aware of IP Fragment attack type of the Intrusion
Detection Services (IDS) enhancements to monitor both IPv4 and IPv6
traffic</h4><a id="idx314"></a><a id="idx315"></a><a id="idx316"></a>
<p>Beginning in z/OS V2R1, IP Fragment attack type of the Intrusion
Detection Services (IDS) is enhanced to monitor both IPv4 and IPv6
traffic for suspicious fragments. It is also enhanced further to check
for overlays that change the data in the packet. <span>Be aware
that in z/OS V2R1, if you have the IP fragment IDS attack enabled,
IPv6 traffic will now be monitored. In earlier releases, only IPv4
traffic was monitored.</span></p>
<table id="wq199" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are using IDS on a stack and the
IP Fragment attack type is enabled.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<p>If you are using IDS on a stack and the IP Fragment attack type
is enabled, be aware of the following information:  
</p>
<ul>
<li>Both IPv4 and IPv6 traffic are monitored for suspicious fragments.</li>
<li>The IP Fragment attack type checking is enhanced to check for
overlays that change the data in the packet, including changes to
the length of the packet.</li></ul>
<p><strong>Reference information</strong>: For more information about IP fragments,
see "Attack of IDS policy definition considerations" in <cite>z/OS Communications Server: IP Configuration Guide</cite>.</p>
<h4 id="dt2mg327">IP Services: Plan for the change of greater than 8 characters
for the FTP password</h4><a id="idx317"></a>
<p>Writer: Jim Guilianelli Developer: Shigeki
Kimura</p>
<p><strong>Description</strong>: Before z/OS V1R13 an FTP password greater than
8 characters was truncated to 8 characters. Starting with V1R13 the
z/OS FTP server supports password phrases. This support passes the
provided password to the installation security product without any
truncation.</p>
<p> The lack of the truncation might cause the FTP server SAF call
to fail. By applying the PTF for APAR PM62213, FTP has been modified
to support a new server FTP.DATA statement called PASSPHRASE. It indicates
whether the FTP server supports logging into FTP with password phrases.
The parameters are:
</p>
<ul>
<li>TRUE:  The FTP server allows an FTP client to log into FTP with
a password phrase. This is the default.</li>
<li>FALSE: The FTP server does not allow an FTP client to log into
FTP with a password phrase.</li></ul><p class="indatacontent">To expect the same behavior as in earlier releases to z/OS V1R13,
you need to specify the FALSE explicitly.</p>
<table id="wq200" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications
Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes,
if you are not using passphrases and wish the existing behavior (prior
to z/OS V1R13) to remain.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td></td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Decide if you need Communications Server
to continue the truncation of passwords for FTP or not.  If you would
like no truncation and intend to use passphrases for FTP, then the
default is acceptable for you.  If you wish to override the default
value and have the z/OS FTP server truncate passwords longer than
8 characters, then override the default for PASSPHRASE in FTP.DATA.</p>
<p><strong>Reference information:</strong> 
See <cite>z/OS Communications Server: IP Configuration Reference</cite>.</p>
<h4 id="dt2mg328">IP Services: Relink NMI applications using the 64-bit TMI copy
buffer function (EZBTMIC4)</h4><a id="idx318"></a><a id="idx319"></a>
<p></p>
<p><strong>Description</strong>: Starting
with z/OS V2R1, the interface between the 64-bit TMI copy buffer function
(EZBTMIC4) and the TCP/IP stack is changed. Applications that use
the real-time TCP/IP network monitoring network management interface
(NMI) and statically link to this function must either relink or change
to dynamic linking or loading of the function.</p>
<table id="wq201" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your application statically links to
the 64-bit TMI copy buffer function (EZBTMIC4). No change is required
for applications that use the 32-bit TMI copy buffer function (EZBTMIC1)
or that dynamically link or load EZBTMIC4.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If
your application statically links to the 64-bit TMI copy buffer function
(EZBTMIC4), relink your application, or change your application to
dynamically link to the 64-bit TMI copy buffer function (EZBTMIC4).</p>
<p><strong>Reference information:</strong> See
"EZBTMIC1 or EZBTMIC4: Copy TCP/IP Management Interface Data Buffer"
in <cite>z/OS Communications Server: IP Programmer&amp;apos;s Guide and Reference.</cite></p>
<h4 id="dt2mg329">IP Services: Review C/C++ applications that use the GetProfile
request of the TCP/IP callable network management interface (NMI)</h4><a id="idx320"></a>
<p></p>
<p><strong>Description</strong>: 
In z/OS V2R1, the definitions of some of the IPv6 address fields returned
by the TCP/IP callable NMI GetProfile request, have changed. The definitions
for the following fields are corrected to specify a data type of in6_addr
instead of a character string in the C/C++ header file ezbnmmpc.h.
</p>
<ul>
<li>NMTP_V6CFDynXcfAddr</li>
<li>NMTP_IPA6Addr</li></ul><p class="indatacontent">If you have C/C++ applications that reference these fields, you
need to modify your application before recompiling it with the updated
C/C++ header file.</p>
<table id="wq202" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you plan on recompiling your application
with the updated C/C++ header file.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ol type="1">
<li>Review the references to the changed fields in your application
program.</li>
<li>If you have C/C++ applications that reference these fields, you
need to modify your application before recompiling it with the updated
C/C++ header file.</li></ol>
<p><strong>Reference information:</strong> 
For more information about the GetProfile request, see "TCP/IP callable
NMI (EZBNMIFR)" in <cite>z/OS Communications Server: IP Programmer&amp;apos;s Guide and Reference.</cite></p>
<h4 id="preparefortheadditionofipv6supportforpolicy-basedrouting">IP Services: Prepare for the addition of IPv6 support for policy-based
routing</h4><a id="idx321"></a>
<p><strong>Description</strong>: As
of z/OS V2R1 policy-based routing is enhanced to route IPv6 traffic.
In earlier releases a policy-based routing rule that did not specify
the source and destination IP addresses only applied to IPv4 packets.
Starting in z/OS V2R1, that same policy-based routing rule applies
to both IPv4 and IPv6 packets.</p>
<table id="wq204" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes,
if you are using policy-based routing on a stack that is being run
as a dual-mode stack (IPv4 and IPv6).</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If you have a policy-based routing rule that
specifies neither source IP addresses nor destination IP addresses,
the rule will apply to both IPv4 and IPv6 packets. If you want the
rule to continue to apply to only IPv4 packets, modify the rule to
specify either a source or destination IP address of 0.0.0.0/0.</p>
<p><strong>Reference information:</strong> See the RoutingRule statement
in <cite>z/OS Communications Server: IP Configuration Reference.</cite></p>
<h4 id="dt2mg330">IP Services: Replace any GATEWAY statements in the TCP/IP profile
 with equivalent  BEGINROUTES statements</h4><a id="idx322"></a><a id="idx323"></a>
<p>[[[[ Contributing writer: Sonja Moore/Durham/Contr/IBM@IBMUS
]]]] [[[[ Original technical contact: Greg Callis/Raleigh/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: As of z/OS V2R1 support for the GATEWAY statement
in the TCP/IP profile is eliminated. The BEGINROUTES/ENDROUTES statement
block was introduced in z/OS V1R1 Communications Server and replaces
the GATEWAY profile statement for configuration of static routes.
 The GATEWAY statement has been stabilized since then, and has not
been updated to support enhancements such as IPv6 and replaceable
static routes. Additionally, the GATEWAY syntax is error prone.</p>
<table id="wq205" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td align="left">Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to take advantage of the
latest support offered by BEGIROUTES/ENDROUTES.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>ZOSMIGV2R1_CS_GATEWAY can help you determine
if you are using any GATEWAY statements in your TCP/IP profile.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Replace any GATEWAY statements in your TCP/IP
profile with the equivalent BEGINROUTES/ENDROUTES statement block.</p>
<p> In order to create BEGINROUTES statements from your existing specification,
you can use IPCS. Run the TCPIPCS PROFILE report on a dump of the
TCP/IP address space and static routes are presented as a BEGINROUTES/ENDROUTES
statement block, even if you coded them by using a GATEWAY statement. .
However, you will have to execute the commands to know with certainty
what changes to make.</p>
<p><strong>Reference information:</strong> 
</p>
<ul>
<li>See "Chapter 2: TCP/IP Profile and Configuration Statements" in <cite>z/OS Communications Server: IP Configuration Reference</cite></li>
<li>See "Chapter 6: PCS Subcommands for TCP/IP" in z/OS Communications Server: IP Diagnosis Guide</li></ul>
<h4 id="bind2">IP Services: Migrate from BIND 9.2.0</h4>
<p>[[[[ Contributing writer: Jie Z Zhu/China/IBM]]]]
[[[[ Technical contact: Andy Tracy/Raleigh/IBM, Joshua Bennetone/Durham/IBM&gt;
]]]]</p>
<p><strong>Description</strong>: z/OS V1R13 was the last release that supported
the z/OS BIND 9.2.0 name server function. If you are using this function
as a name server, you must find a replacement.</p>
<table id="wq206" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx324"></a><a id="idx325"></a><a id="idx326"></a><strong>Element or feature</strong>:</td>
<td>Communications Server</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>The removal of the BIND 9.2.0 function was first
announced in February 2009. z/OS V1R13 was the last release that supported
the z/OS BIND 9.2.0 name server function, as stated in the z/OS V1R13
preview announcement on February 11th, 2011.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are using the BIND 9.2.0 function
as a name server.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ul>
<li>If you are using z/OS BIND 9.2.0 as a caching-only name server,
use the z/OS resolver DNS caching function to cache DNS responses.</li>
<li>If you are using z/OS BIND 9.2.0 as a primary or secondary authoritative
name server, investigate using BIND on Linux for System z or BIND
on an IBM blade in a zBX.</li>
<li>Update the NSINTERADDR statements in the resolver configuration
file.</li>
<li>If the z/OS BIND 9.2.0 name server is the only name server to
be contacted in the NSINTERADDR list of name servers, replace the
name server entry with one or more name server IP addresses.</li>
<li>If more than one name server is in the NSINTERADDR list of name
servers, delete the IP address of the z/OS BIND 9.2.0 name server.</li>
<li>If the automated domain name registration(ADNR) application is
being used, ensure the name server is configured to support ADNR.
 See <cite>z/OS Communications Server: IP Configuration Guide</cite> for
configuring automated domain name registration.</li></ul>
<p><strong>Reference information</strong>: For details about the resolver, see <cite>z/OS Communications Server: IP Configuration Guide</cite> and <cite>z/OS Communications Server: IP Configuration Reference</cite>.</p>
<h3 id="e0z3m100-gen27">Communications Server actions to perform before the first IPL
of z/OS V2R1</h3>
<p>This topic describes Communications Server migration actions
that you can perform after you have installed z/OS V2R1 but before the first time you IPL.
These actions might require the z/OS V2R1 level of code to be installed
but do not require it to be active.</p>
<p><a href="e0z3m100.htm#dt2mg340">IP Services: Remove ICLI component from z/OS</a></p>
<p><a href="e0z3m100.htm#dt2mg342">IP Services: If the NSS daemon is configured in FIPS 140 mode,
ensure ICSF is active before starting the daemon.</a></p>
<p><a href="e0z3m100.htm#dt2mg343">IP Services: If the IKE daemon is configured in FIPS 140 mode,
ensure ICSF is active before starting the daemon.</a></p>
<p><a href="e0z3m100.htm#dt2mg345">IP Services: Allow users of AT-TLS access to CSFIQA and CSFRNG
resources of the CSFSERV class if ICSF will be used with AT-TLS</a></p>
<p><a href="e0z3m100.htm#ipauto">IP Services: Update automation on D TCPIP,tnproc,&lt;Telnet&gt;,CONN
 for the expanded EN TY column in message EZZ6064I</a></p>
<p><a href="e0z3m100.htm#resolver">IP Services: Update automation to monitor resolver address
space initialization completion messages</a></p>
<p><a href="e0z3m100.htm#omroute">IP Services: Update OMPROUTE configuration procedures for OMPROUTE_OPTIONS</a></p>
<p><a href="e0z3m100.htm#dt2mg346">IP Services: Check the values specified for TCP related configuration
statements.</a></p>
<p><a href="e0z3m100.htm#dt2mg347">IP Services: Make changes for Netstat enhancements</a></p>
<p><a href="e0z3m100.htm#dt2mg345">IP Services: Allow users of AT-TLS access to CSFIQA and CSFRNG
resources of the CSFSERV class if ICSF will be used with AT-TLS</a></p>
<p><a href="e0z3m100.htm#upcsetc">IP Services: Update /etc configuration files</a></p>
<h4 id="dt2mg340">IP Services: Remove ICLI component from z/OS</h4><a id="idx327"></a><a id="idx328"></a>
<p>[[[[ Contributing writer: Jim Guilianelli]]]]
[[[[ Original technical contact: Greg Callis/Raleigh/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: IBM intends to remove the Integrated Call Level
Interface (ICLI) in z/OS z/OS V2R1. ICLI is used by those who have
requested and obtained the ICLI API documentation and the C language
header file. IBM believes that users of this interface have changed
from using ICLI to standard IBM DB2 Connect for database connectivity
and do not need it when z/OS V2R1 becomes available. ICLI has not
been enhanced since z/OS 1.6. IBM intends to exclude ICLI from releases
after z/OS V1R13.</p>
<table id="wq207" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td align="left">Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended?</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>ZOSMIGV2R1_CS_GATEWAY can help you determine
if you are using any GATEWAY statements in your TCP/IP profile.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Reomve the ICLI component. To identify the
ICLI components examine the ibmicli.h header file?????????? Contact
your IBM representative if you have questions?</p>
<p><strong>Reference information:</strong> None.</p>
<h4 id="dt2mg342">IP Services: If the NSS daemon is configured in FIPS 140 mode,
ensure ICSF is active before starting the daemon.</h4><a id="idx329"></a>
<p></p>
<p><strong>Description</strong>: FIPS
140 support now requires ICSF services.  If the NSS daemon is configured
in FIPS 140 mode, the daemon will fail to activate if ICSF is not
active.  Ensure ICSF is started prior to starting the NSS daemon if
the NSS daemon is configured in FIPS 140 mode.</p>
<table id="wq208" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the NSS daemon is configured in FIPS
140 mode.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>ICSF.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If
the NSS daemon is configured in FIPS 140 mode, ensure ICSF is active
prior to starting the NSS daemon.</p>
<p><strong>Reference information:</strong> See &quot;Steps for preparing the z/OS
system for IP security&quot; and &quot;Steps for configuring IP security to
support FIPS 140 mode&quot; in "Chapter 19 IP Security" in <cite>z/OS Communications Server: IP Configuration Guide</cite>.</p>
<h4 id="dt2mg343">IP Services: If the IKE daemon is configured in FIPS 140 mode,
ensure ICSF is active before starting the daemon.</h4><a id="idx330"></a>
<p></p>
<p><strong>Description</strong>: FIPS
140 support now requires ICSF services.  If the IKE daemon is configured
in FIPS 140 mode, the daemon will fail to activate if ICSF is not
active.  Ensure ICSF is started prior to starting the IKE daemon if
the IKE daemon is configured in FIPS 140 mode.</p>
<table id="wq209" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the IKE daemon is configured in FIPS
140 mode.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>ICSF.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If
the IKE daemon is configured in FIPS 140 mode, ensure ICSF is active
prior to starting the IKE daemon.</p>
<p><strong>Reference information:</strong> See
&quot;Steps for preparing the z/OS system for IP security&quot; and &quot;Steps for
configuring IP security to support FIPS 140 mode&quot; in Chapter 19 IP
Security in <a href="./f1a2b300.html#f1a2b300">z/OS Communications Server: IP Configuration Guide</a>
for additional information.</p>
<h4 id="dt2mg345">IP Services: Allow users of AT-TLS access to CSFIQA and CSFRNG
resources of the CSFSERV class if ICSF will be used with AT-TLS</h4><a id="idx331"></a><a id="idx332"></a>
<p></p>
<p><strong>Description</strong>: Starting in z/OS V2R1, System SSL will attempt
to use ICSF services if ICSF is active during AT-TLS group initialization.
If ICSF is active and the CSFSERV class is active, the userid associated
with TCP/IP stack should have READ access to the CSFIQA and CSFRNG
resources of the CSFSERV class. This will allow System SSL to be aware
of the hardware available with ICSF and use ICSF to generate random
numbers during initialization. Application userids using AT-TLS groups
should also be given READ access to the CSFRNG resource of the CSFSERV
class.</p>
<table id="wq210" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:. 
</p>
<ol type="1">
<li>If the CSFSERV class is active, give READ access to the userid
associated with the TCP/IP stack and any application userid using
the TTLSGroup to the CSFRNG resource within the CSFSERV class.</li>
<li>If the CSFSERV class is active, give READ access to the userid
associated with the TCP/IP stack to the CSFIQA resource within the
CSFSERV class.</li></ol>
<p><strong>Reference information:</strong> See &quot;See Chapter 3. Using Cryptographic
Features with System SSL" in <cite>z/OS Cryptographic Services System SSL Programming</cite>.</p>
<h4 id="ipauto">IP Services: Update automation on D TCPIP,tnproc,&lt;Telnet&gt;,CONN
 for the expanded EN TY column in message EZZ6064I</h4><a id="idx333"></a><a id="idx334"></a><a id="idx335"></a>
<p><strong>Description</strong>: Message EZZ6064I, which is issued
in response to a D TCPIP,tnproc,&lt;Telnet&gt;,CONN command,  is expanded
by two bytes to show a four byte cipher value when the connection
is secured with AT-TLS.  As a result of this change, the previous
column header of "EN TY" has been changed to "ENCR TYPE"  The cipher
value can be up to four bytes in length. Cipher values less than four
bytes are padded with blanks.</p>
<table id="wq212" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Communications Server</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if automating on the  D TCPIP,tnproc,&lt;Telnet&gt;,CONN
command message EZZ6064I.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>The AT-TLS group configured with FIPS140-2 will
fail to initialize if ICSF is not active.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ul>
<li>Be aware of the changes in message EZZ6064I.</li>
<li>Update any automation on  D TCPIP,tnproc,&lt;Telnet&gt;,CONN 
message EZZ6064I.</li></ul>
<p><strong>Reference information</strong>: See an example of the updated "D
TCPIP,tnproc,&lt;Telnet&gt;,CONN output" in <cite>z/OS Communications Server: IP System Administrator&amp;apos;s Commands</cite>.</p>
<h4 id="resolver2">IP Services: Update automation to monitor resolver address
space initialization completion messages</h4><a id="idx336"></a><a id="idx337"></a><a id="idx338"></a><a id="idx339"></a><a id="idx340"></a><a id="idx341"></a>
<p>[[[[ Contributing writer: Jie Z Zhu/China/IBM]]]]
[[[[ Technical contact: Michael Gierlach/Raleigh/IBM&gt; ]]]]</p>
<p><strong>Description</strong>: Beginning with z/OS V2R1, the resolver processes
the entire resolver setup file during resolver address space initialization.
When the resolver detects syntax errors or when it does not recognize
the resolver setup statement, the resolver ignores the setup file
statement and the resolver initialization completes successfully with
warning messages. Ignoring the setup file statement might result in
the resolver using default settings for some resolver setup statements
if the statement was specified with errors.</p>
<p>If the resolver issues warning messages during address space initialization,
the resolver issues message EZD2038I instead of message EZZ9293I when
the initialization completes.<a id="idx342"></a><a id="idx343"></a><a id="idx344"></a></p>
<table id="wq213" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Communications Server</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you customize the resolver and want
to correct any errors that the resolver finds in the resolver setup
file.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>The resolver might initialize with the incorrect
configuration because of errors in the setup file, which might cause
applications issuing resolver API calls to get erroneous results.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<p>If you customize the resolver and want to detect when
the resolver ignores errors in the resolver setup file during address
space initialization, do the following:  
</p>
<ul>
<li>Monitor resolver address space initialization for message
EZD2038I RESOLVER INITIALIZATION COMPLETED WITH WARNINGS.</li>
<li>Issue the MODIFY RESOLVER,DISPLAY command after system
initialization completed to determine if the following message has
been issued in the display output:  
<pre class="xmp"><code>EZD2039I WARNINGS ISSUED DURING RESOLVER INITIALIZATION</code></pre></li></ul><p class="indatacontent">If the resolver issues the message EZD2038I or EZD2039I, take
the following steps:</p>
<ol type="1">
<li>Collect the system console messages that are issued by the resolver
during resolver address space initialization.</li>
<li>Contact the system programmer. The system programmer needs to
use the resolver warning messages to correct the errors in the resolver
setup file.</li>
<li>When the errors are corrected, the network operator needs to issue
a MODIFY RESOLVER,REFRESH,SETUP=setup_file command to correct the
resolver configuration.</li></ol>
<p><strong>Reference information</strong>: For more information about the resolver,
see "Customizing the resolver" in <cite>z/OS Communications Server: IP Configuration Guide</cite>.</p>
<h4 id="omroute">IP Services: Update OMPROUTE configuration procedures for OMPROUTE_OPTIONS</h4>
<p>[[[[ Contributing writer: Jie Z Zhu/China/IBM]]]]
[[[[ Technical contact: Jon Bell/Raleigh/IBM&gt; ]]]]</p>
<p><strong>Description</strong>: Before z/OS V2R1, the OMPROUTE_OPTIONS environment
variable was used by OMPROUTE to set various controls for OMPROUTE
processing and only the hello_hi option was supported. The hello_hi
option optimized the processing of OSPF Hello packets in OMPROUTE
 to minimize the potential adjacency failures with neighbors.</p>
<p>Beginning with z/OS V2R1, the OMPROUTE_OPTIONS environment
variable is ignored and will not be supported in a future release.
The optimization function for OSPF Hello packets is always enabled</p>
<p>If the environment variable, OMPROUTE_OPTIONS, is configured
then the following message will be issued to the console or hardcopy
log:</p>
<pre class="xmp"><code>EZZ8172I <em>jobname</em> IGNORING ENVIRONMENT VARIABLE OMPROUTE_OPTIONS WHICH WILL BE 
RETIRED IN A FUTURE RELEASE </code></pre>
<table id="wq215" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx345"></a><a id="idx346"></a><a id="idx347"></a><a id="idx348"></a><strong>Element
or feature</strong>:</td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if the environment variable
OMROUTE_OPTIONS=hello_hi is coded.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  If you want to suppress the warning
message that the environment variable OMPROUTE_OPTIONS is to be retired
in a future release, remove the environment variable from the OMPROUTE
environment variable file.</p>
<p><strong>Reference information</strong>:  See "Steps for Configuring
OMPROUTE" in <cite>z/OS Communications Server: IP Configuration Guide</cite>.</p>
<h4 id="dt2mg346">IP Services: Check the values specified for TCP related configuration
statements.</h4><a id="idx349"></a>
<p></p>
<p><strong>Description</strong>: As of z/OS V2R1 the default values
for TCPRCVBUFRSIZE and TCPSENDBUFRSIZE parameters on the TCPCONFIG
statement have been increased from 16K to 64K. Increasing the receive
or send buffer size does not in itself allocate or consume any additional
storage.  The receive and send buffer sizes determine the amount of
data that can be buffered by TCPIP for the application. The increase
in the default values can allow more data to be buffered and consequently,
more storage to be used.</p>
<p>The default value for the SOMAXCONN statement has increased from
10 to 1024. The SOMAXCONN value limits what a server application can
specify for its listening backlog.</p>
<p>The amount of time a connection remains in FINWAIT2 has been changed
to use the value specified on the TCPCONFIG parameter FINWAIT2. Previously,
an additional seventy five seconds was added to the time specified
on the FINWAIT2 parameter before the connection was dropped</p>
<table id="wq216" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
the first IPL of z/OS V2R1..</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes,
for one of the following conditions:

<ul>
<li>If the potential increase in the size of the send and receive
buffers is likely to cause a storage shortage</li>
<li>If you used the current defaulted value of SOMAXCONN to limit
applications from specifying a listening backlog larger than 10</li>
<li>If you require the additional seventy-five seconds before the
connection is dropped</li></ul></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  If needed, do the following:
</p>
<ul>
<li>Change the TCPRCVBUFRSIZE and TCPSENDBUFRSIZE values to 16K. C</li>
<li>Change the SOMAXCONN value to 10.</li>
<li>Increase the FINWAIT2 value by 75 seconds.</li></ul>
<p><strong>Reference information</strong>: See an example of the updated "D
TCPIP,tnproc,&lt;Telnet&gt;,CONN output" in <cite>z/OS Communications Server: IP Configuration Reference</cite>.</p>
<h4 id="dt2mg347">IP Services: Make changes for Netstat enhancements</h4><a id="idx350"></a><a id="idx351"></a>
<p>[[[[ Contributing writer: Sonja Moore/Durham/Contr/IBM@IBMUS
]]]] [[[[ Original technical contact: Greg Callis/Raleigh/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: The Netstat command displays the status of
a local host. Each release, the Netstat reports are changed in ways
that can affect automation or front-end programs.</p>
<table id="wq217" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td align="left">Before the first IPL of z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the changed or removed settings affect
either (1) automation that uses the Netstat report output or (2) front-end
programs that invoke the Netstat command.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None..</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Accommodate Netstat changes in your automation
and front-end programs. You can begin planning your changes by reviewing
the ways in which the displays are updated each release. For details
about how each Netstat report has changed, see z/OS Summary of Message
and Interface Changes. However, you will have to execute the commands
to know with certainty what changes to make.</p>
<p><strong>Reference information:</strong> 
</p>
<ul>
<li>For details about using Netstat, see z/OS Communications Server:
IP System Administrator's Commands. <cite>z/OS Communications Server: IP Configuration Reference</cite></li>
<li>For details about Netstat report changes, see z/OS Communications Server: IP Diagnosis Guide</li></ul>
<h4 id="upcsetc">IP Services: Update /etc configuration files</h4>
<p>[[[[ Technical contact: Kristine Adamson/Raleigh/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: Some utilities provided by Communications Server
require the use of certain configuration files. You are responsible
for providing these files if you expect to use the utilities. IBM provides default configuration
files as samples in the <samp class="xph">/usr/lpp/tcpip/samples</samp> directory.
Before the first use of any of these utilities, you should copy these
IBM-provided samples to the <samp class="xph">/etc</samp> directory (in most
cases). You can further customize these files to include installation-dependent
information. An example is setting up the <samp class="xph">/etc/osnmpd.data</samp> file
by copying the sample file from <samp class="xph">/usr/lpp/tcpip/samples/osnmpd.data</samp> to <samp class="xph">/etc/osnmpd.data</samp> and
then customizing it for the installation.</p>
<p>If you customized any of the configuration files that have changed,
then you must incorporate the customization into the new versions
of the configuration files.</p>
<table id="wq218" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>Various releases. See <a href="e0z3m100.htm#upcsetc__csetctb">Table 10</a>.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have customized a configuration
file (listed in <a href="e0z3m100.htm#upcsetc__csetctb">Table 10</a>) that IBM has changed.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  If you added installation-dependent customization
to any of the IBM-provided configuration files listed in <a href="e0z3m100.htm#upcsetc__csetctb">Table 10</a>, make the same changes in the new
versions of the files by copying the IBM-provided samples to the files
shown in the table and then customizing the files.</p>
<table id="upcsetc__csetctb" width="100%" summary="" border="1" frame="border" rules="all" class="presentation" role="presentation">
<caption><a href="e0z3m100.htm#FT_Table_10">Table 10. Changed Communications Server configuration files</a></caption>
<thead valign="bottom">
<tr>
<th id="wq219" width="19%" align="left" valign="bottom">Utility</th>
<th id="wq220" width="34%" align="left" valign="bottom">IBM-provided sample file</th>
<th id="wq221" width="15%" align="left" valign="bottom">Target location</th>
<th id="wq222" width="30%" align="left" valign="bottom">What changed and when</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left" valign="top" headers="wq219">SNMP agent</td>
<td align="left" valign="top" headers="wq220">/usr/lpp/tcpip/samples/osnmpd.data</td>
<td align="left" valign="top" headers="wq221">/etc/osnmpd.data</td>
<td align="left" valign="top" headers="wq222">Every release, the value of the sysName
MIB object is updated to the current release.</td>
</tr>
<tr>
<td align="left" headers="wq219">File Transfer Protocol Daemon
(FTPD)</td>
<td align="left" headers="wq220">SEZAINST(FTPSDATA)</td>
<td align="left" headers="wq221">/etc/ftp.data</td>
<td align="left" headers="wq222">In z/OS V2R1, a new configuration
statement is provided to specify that a type 119 SMF record of subtype
71 is collected for the FTP daemon configuration information when
the FTP daemon starts.</td>
</tr>
</tbody>
</table>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li>For more details about configuration files, see <cite>z/OS Communications Server: IP Configuration Guide</cite>.</li>
<li>For information about modifying the NFS samples, see Chapter 10
in <cite>z/OS Network File System Guide and Reference</cite>.</li></ul>
<h3 id="e0z3m100-gen28">Communications Server actions to perform after the first IPL
of z/OS V2R1</h3>
<p>This topic describes Communications Server migration actions
that you can perform only after you have IPLed z/OS V2R1. You need a running z/OS V2R1 system to perform these actions.</p>
<p>None.<a id="idx352"></a><a id="idx353"></a><a id="idx354"></a><a id="idx355"></a><a id="idx356"></a><a id="idx357"></a></p>
<h2 id="ae1cryp">Cryptographic Services migration actions</h2>
<p>This topic describes migration actions for base element Cryptographic
Services. Included are the components Integrated Cryptographic Service
Facility (ICSF), Open Cryptographic Services Facility (OCSF), PKI
Services, and System Secure Sockets Layer (SSL).</p>
<p>NOTE TO REVIEWERS: ADDITIONAL ACTINS WILL BE PRVIDED IN
THE NEXT REVIEW DRAFT.</p>
<h3 id="e0z3m100-gen29">Cryptographic Services actions to perform before installing
z/OS V2R1</h3><a id="idx358"></a><a id="idx359"></a><a id="idx360"></a>
<p>This topic describes Cryptographic Services migration actions that
you can perform on your current (old) system. You do not need the z/OS V2R1 level of code to make
these changes, and the changes do not require the z/OS V2R1 level of code to run once they are made.</p>
<h3 id="e0z3m100-gen106">Cryptographic Services actions to perform before the first
IPL of z/OS V2R1</h3>
<p>This topic describes Cryptographic Services migration actions that
you can perform after you have installed z/OS V2R1 but before the first time you IPL.
These actions might require the z/OS V2R1
level of code to be installed but do not require it to be active.</p>
<p><a href="e0z3m100.htm#pkcs111">ICSF: Start using ICSF in FIPS mode for PKCS #11 Diffie Hellman
support to generate key parameters, key pairs, and key exchanges</a></p>
<p><a href="e0z3m100.htm#ae3ois">OCSF: Migrate the directory structure</a></p>
<p><a href="./SSL_V2R1_sslfips_v2r1_12.html">System SSL: Ensure ICSF is available when running System SSL
in FIPS mode</a></p>
<p><a href="e0z3m100.htm#csfserv">System SSL:  Ensure all RACF user IDs that start SSL applications
in non-FIPS mode can access the CSFRNG resource of the CSFSERV class</a></p>
<h4 id="pkcs111">ICSF: Start using ICSF in FIPS mode for PKCS #11 Diffie Hellman
support to generate key parameters, key pairs, and key exchanges</h4>
<p>[[[[ Marna Walle]]]]</p>
<p>In z/OS V2R1, System Security uses the ICSF PKCS #11 CSFPPRF pseudo-random
function for generation of random data. In non-FIPS mode the previous
software implementation remains as a back up random number generator;
however, in FIPS mode, this backup will be unavailable..</p>
<table id="wq223" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Cryptographic Services.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>ICSF FMID HCR77A1, which was initially made
available in web deliverable Cryptographic Support for z/OS V1R13-V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ul>
<li>Review applications that uses Security Server SSL in both non-FIPS
or FIPS mode.</li>
<li>For FIPS-mode applications: 

<ul>
<li>Ensure ICSF has been configured and started on the system
in FIPS mode.</li>
<li>Ensure that the application userID has READ access to at least
the CSFRNG resource in the RACF CSFSERV class, if the CSFSERV class
has been defined.</li>
<li>If the application uses Diffie-Hellman by specifying either a
Diffie-Hellman cipher for a SSL/TLS handshake, using Diffie-Hellman
certificates, or creating Diffie-Hellman key parameters and keys,
ensure the application userID has READ access to the CSF1TRC, CSF1DVK,
CSF1GKP, CSF1GSK, CSF1GAV and CSF1TRD resources in the RACF CSFSERV
class, if the CSFSERV class has been defined.</li></ul></li>
<li>For non-FIPS mode applications: 

<ul>
<li>If ICSF has been configured and started on the system, ensure
the application userID has READ access to at least the CSFRNG resource
in the RACF CSFSERV class, if the CSFSERV class has been defined.
 Without access to the resource, informational message ICH408I will
be displayed and System SSL will switch to using its software version
of Random Number Generate.</li></ul></li></ul>
<p><strong>Reference information</strong>: <cite>z/OS Cryptographic Services System SSL Programming</cite>.</p>
<h4 id="ae3ois">OCSF: Migrate the directory structure</h4><a id="idx361"></a><a id="idx362"></a><a id="idx363"></a><a id="idx364"></a><a id="idx365"></a><a id="idx366"></a>
<p><strong>Description</strong>: If you previously configured Open Cryptographic
Services Facility (OCSF), you need to verify that the OCSF directories
have been migrated to the target system.
 </p>
<div>
<div class="note-noindent" id="wq224">
<span class="notetitle">Note:</span> <span class="notebody"> If you want to take advantage of the new Software
Cryptographic Service Provider 2 (SWCSP2), you should bypass this
migration action.  When your system is up and running, install OCSF
by running the install script and then the IVP.</span></div></div><a id="idx367"></a>
<table id="wq225" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Cryptographic Services.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you currently use OCSF or if new products
or functions on your new z/OS system require OCSF to be active. However,
if you installed your new z/OS system
with ServerPac or SystemPac,
the OCSF installation script has been run and you do not have to perform
this migration action for that system.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Migrate the OCSF <samp class="xph">/var</samp> directory
structure to the target system. If you installed z/OS V1R11 with CBPDO or by cloning an already-installed
V1R11 system, you can either copy  the <samp class="xph">/var/ocsf</samp> directory
from your old system or rerun the installation script. If you installed z/OS V1R11 with ServerPac or SystemPac, the OCSF installation
script has been run and you have no migration actions for that target
system (although you still have to migrate the directory structure
to any cloned systems, as stated above).</p>
<p>If you copy <samp class="xph">/var/ocsf</samp>, verify that the OCSF <samp class="xph">/var</samp> directory
structure has been migrated to the target system as described in <a href="e0z3m100.htm#at3gend">Migrate /etc and /var system control files</a>. The OCSF registry (the <samp class="xph">/var/ocsf</samp> files)
contains the directory path names to the code libraries. If the registry
files are copied, the CSSM DLL and the add-ins must be in the same
location on the target system as on the prior release.  The normal
locations are <samp class="xph">/usr/lpp/ocsf/lib</samp> for the CSSM and
supporting DLLs and <samp class="xph">/usr/lpp/ocsf/addins</samp> for the
add-in libraries.</p>
<p>If you copied <samp class="xph">/var/ocsf</samp>, do the following:</p>
<ol type="1">
<li>Verify that the following four files exist in that directory: 

<ul>
<li>CDSA_Registry.dir with permissions (-rw-r--r--)</li>
<li>CDSA_Registry.pag with permissions ( -rw-r--r--)</li>
<li>CDSA_Sections.dir with permissions (-rw-r--r-- )</li>
<li>CDSA_Sections.pag with permissions (-rw-r--r--)</li></ul></li>
<li>Verify that the required RACF FACILITY
class profiles are defined and set up:<a id="idx368"></a>  

<ul>
<li>CDS.CSSM -- authorizes the daemon to call OCSF services</li>
<li>CDS.CSSM.CRYPTO -- authorizes the daemon to call a cryptographic
service provider (CSP)</li>
<li>CDS.CSSM.DATALIB -- authorizes the daemon to call a data storage
library (DL) service provider</li></ul></li>
<li>Ensure that the necessary libraries are program controlled: 

<ul>
<li>XL C/C++ runtime libraries</li>
<li>Language Environment libraries</li>
<li>SYS1.LINKLIB</li>
<li>SYS1.SIEALNKE</li></ul></li></ol>
<p>If you did not copy <samp class="xph">/var/ocsf</samp>, rerun the installation
script:</p>
<ol type="1">
<li>Set up the RACF FACILITY
class profiles required by OCSF and authorize the appropriate
user IDs to those profiles: 

<ul>
<li>CDS.CSSM -- authorizes the daemon to call OCSF services</li>
<li>CDS.CSSM.CRYPTO -- authorizes the daemon to call a cryptographic
service provider (CSP)</li>
<li>CDS.CSSM.DATALIB -- authorizes the daemon to call a data storage
library (DL) service provider</li></ul></li>
<li>Ensure that the following libraries are defined as program controlled: 

<ul>
<li>XL C/C++ runtime libraries</li>
<li>Language Environment libraries</li>
<li>SYS1.LINKLIB</li>
<li>SYS1.SIEALNKE</li></ul></li>
<li>Run the <strong>ocsf_install_crypto</strong> script from the OMVS shell.
This must be run from the target system.  

<ol type="a">
<li>Verify and update $LIBPATH.</li>
<li>Change directory to the location of the script (<samp class="xph">/usr/lpp/ocsf/bin</samp>).</li>
<li>Run the script.</li></ol></li></ol>
<p>Whether you reinstalled or migrated, it is strongly recommended
that you rerun IVP <strong>ocsf_baseivp</strong> from the OMVS shell. This IVP
verifies that OCSF is installed and configured correctly. To run the
IVP:</p>
<ol type="1">
<li>Mount <samp class="xph">/usr/lpp/ocsf/ivp</samp>.</li>
<li>Read the README file and follow the instructions.</li>
<li>Run the IVP.</li></ol>
<p>If you were using other IBM or
non-IBM services to supplement the functions in OCSF, such as the
Open Cryptographic Enhanced Plug-ins (OCEP) component of base element
Integrated Security Services, or the PKI Services component of base
element Cryptographic Services, you must ensure that these are migrated
or reinstalled.</p>
<p><strong>Reference information</strong>: .</p>
<h4 id="icsf_fips1">System SSL: Ensure ICSF is available when running System SSL
in FIPS mode</h4><a id="idx369"></a><a id="idx370"></a>
<p>[[[[ Tim Flaherty ]]]] [[[[ Technical
contact: Alyson Comer ]]]]</p>
<p><strong>Description</strong>: In z/OS V2R1, System SSL, when running
in FIPS mode, uses ICSF's random number generation and Diffie-Hellman
support. Before running System SSL in FIPS mode you must ensure that
ICSF is running and that all user IDs that start SSL applications
in FIPS mode, invoke the gskkyman utility to manage FIPS
key database files, or invoke the GSKSRVR started task in FIPS mode
have access to certain CSFSERV classes.</p>
<p>When it is running in non-FIPS mode, System SSL uses its
own implementation of Diffie-Hellman and does not require ICSF. In
non-FIPS mode, however, System SSL attempts to use ICSF's random number
generation as it would when running in FIPS mode. If ICSF or the required
resource is unavailable, System SSL uses its own random number generation
capabilities as in earlier releases.</p>
<table id="wq230" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx371"></a><a id="idx372"></a><strong>Element
or feature</strong>:</td>
<td>Cryptographic Services.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td align="left">ICSF FMID HCR77A1, which was initially
made available in web deliverable Cryptographic Support for z/OS V1R13-V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your installation runs System SSL in
FIPS mode.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: To run System SSL in FIPS mode,
you must now make sure that ICSF is running and that all user IDs
that start SSL applications in FIPS mode, invoke the GSKSRVR started
task in FIPS mode, or invoke the gskkyman utility to manage
FIPS key database files can access the necessary ICSF callable services.</p>
<p></p>
<ol type="1">
<li>Make sure that ICSF is running. Assuming CSF is the name of the
ICSF started task, you would enter:
<pre class="xmp"><code>DISPLAY A,CSF*</code></pre>

<p>To
display status about all started tasks, you would enter:</p>
<pre class="xmp"><code>DISPLAY A,ALL</code></pre>

<p>In
z/OS V1R12 and V1R13, System SSL is providing capability to identify
System SSL applications that are running in FIPS mode, which are started
before ICSF is available.  Identification of these applications is
done by using the System SSL started task (GSKSRVR) and the z/OS tracking
facility.  This migration assistance support is delivered in APAR
OA40816. See <em>Documentation updates for FIPS ICSF tracking support</em> for
more information.</p></li>
<li>System SSL applications that are running in FIPS mode, the GSKSRVR
started task that is running in FIPS mode, and the gskkyman utility
(if managing FIPS key database files) must be able to access ICSF's
PKCS #11 pseudo-random function callable service for random number
generation. In addition, applications and the gskkyman utility
must access the following callable services to use ICSF's Diffie-Hellman
capabilities:

<ul>
<li>PKCS #11 Token record create</li>
<li>PKCS #11 Derive key</li>
<li>PKCS #11 Generate key pair</li>
<li>PKCS #11 Generate secret key</li>
<li>PKCS #11 Get attribute value</li>
<li>PKCS #11 Token record delete</li></ul>To ensure that RACF user IDs have access to the necessary services:

<ol type="a">
<li>Determine if the CSFSERV class is active. If active, this class
restricts access to the ICSF programming interface. If it is not active,
access to the ICSF programming interface (and the necessary callable
services) is unrestricted. No configuration is necessary.

<p>To determine
which RACF classes are currently active, enter the SETROPTS command
with the LIST parameter specified.SETROPTS LIST</p></li>
<li>If the SETROPTS LIST command shows that the CSFSERV class is active,
identify the profile or profiles that cover the following resources:

<ul>
<li>CSFRNG (which represents the PKCS #11 Pseudo-random function callable
service)</li>
<li>CSF1TRC (which represents the PKCS #11 Token record create callable
service)</li>
<li>CSF1DVK (which represents the PKCS #11 Derive key callable service)</li>
<li>CSF1GKP (which represents the PKCS #11 Generate key pair callable
service)</li>
<li>CSF1GSK (which represents the PKCS #11 Generate secret key callable
service)</li>
<li>CSF1GAV (which represents the PKCS #11 Get attribute value callable
service)</li>
<li>CSF1TRD (which represents the PKCS #11 Token record delete callable
service)</li></ul>Each of these resources can be covered by a discrete profile
or, if generic profile checking is activated, a generic profile. You
can use the RLIST command to determine if a profile is defined to
protect each resource. For example, to determine if a profile is defined
to protect the CSFRNG resource, enter the following RLIST command:
RLIST CSFSERV CSFRNG. When you enter this command, RACF lists information
for the discrete profile CSFRNG. If there is no matching discrete
profile, RACF lists the generic profile that most closely matches
the resource name.</li>
<li>If the RLIST command output reveals that there is a discrete or
generic profile that covers the resource, examine the command output
to ensure that all RACF user IDs that might start System SSL applications
in FIPS mode have at least READ access to the resource. If necessary,
use the PERMIT command to give the appropriate users or groups access.
For example, if a discrete profile CSFRNG exists, the following command
would give the user JASMINE access:
<pre class="xmp"><code>PERMIT CSFRNG CLASS(CSFSERV) ID(JASMINE) ACCESS(READ)</code></pre>If
you do make changes, refresh the in-storage RACF profiles for the
CSFSERV class: SETROPTS RACLIST(CSFSERV) REFRESH</li></ol></li></ol>
<p><strong>Documentation updates for FIPS ICSF tracking support:</strong></p>
<p>This documentation contains updates to the following chapters of
z/OS V1R12 and V1R13 <cite>z/OS Cryptographic Services System SSL ProgrammingSC14-7495</cite>:
</p>
<ul>
<li>System SSL and FIPS 140-2: Added a section about how to enable
and use the migration assistance support.</li>
<li>SSL started task chapter: Added GSKSRVR environment variable definitions.</li>
<li>Messages and codes, SSL started task messages (GSK01nnn) section:
Added SSL started task messages, GSK01058I, GSK01059I, GSK01060E,
GSK01061I GSK01062I, and GSK01063I</li></ul>
<p><strong>Reference information</strong>: For additional information about
System SSL use of ICSF callable services, see<cite>z/OS Cryptographic Services System SSL Programming, SC14-7495</cite>.</p>
<p>For additional information on the ICSF installation options file,
refer to <cite>z/OS Cryptographic Services ICSF System Programmer&amp;apos;s Guide</cite>.</p>
<p>For additional information about ICSF's CSFSERV resource class
and the Installation Option Display panel, refer to <cite>z/OS Cryptographic Services ICSF Administrator&amp;apos;s Guide, SA22-7521</cite>.</p>
<h4 id="csfserv">System SSL:  Ensure all RACF user IDs that start SSL applications
in non-FIPS mode can access the CSFRNG resource of the CSFSERV class</h4>
<p>[[[[ Tim Flaherty ]]]] [[[[ Technical
contact: Alyson Comer ]]]]</p>
<p><strong>Description</strong>: Before z/OS V2.1, System SSL always
used its own random number generation support available in software.
As of z/OS V2R1, System SSL now exploits ICSF random number generation
support if ICSF is available. In order to utilize ICSF when the random
number generation service is protected by a RACF resource profile
(CSFRNG), the userid under which the application is executing must
have at least READ access to the resource profile. If the application
is not FIPS enabled the processing is able to fall back to our software
implementation and allow the application to continue (as a result,
you might receive RACF unauthorized messages). If the application
is FIPS enabled, it will fail.</p>
<p>If the user ID that starts the SSL application cannot
access the CSFRNG resource of the CSFSERV class, System SSL will not
be able to use the PKCS #11 Pseudo-random function callable service,
and the informational message ICH408I (which indicates insufficient
authorization) may be issued to the console. Although System SSL processing
will continue, your application will be using System SSL's random
number generation and will not be exploiting the random number generation
capability provided by ICSF software or the Crypto Express3 Coprocessor
(Crypto Express3 Coprocessor card or Crypto Express4 Coprocessor card).</p>
<table id="wq233" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx373"></a><a id="idx374"></a><strong>Element
or feature</strong>:</td>
<td>Cryptographic Services.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>ICSF FMID HCR77A1, which was initially made
available in web deliverable Cryptographic Support for z/OS V1R13-V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the following conditions are true:

<ul>
<li>Your installation uses ICSF.</li>
<li>The CSFSERV general resource class is active.</li>
<li>A profile covering the CSFRNG resource of the CSFSERV class is
defined and does not grant READ access to all users.</li></ul></td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>CSF might employ one of multiple techniques
to derive the random content. For both FIPS certified random content
and for non-FIPS certified random content, the availability of CCA
and/or PKCS #11 coprocessors enables ICSF to derive the random content
without imposing significant CPU overhead on the system. Either type
of coprocessor can be exploited for non-FIPS certified content, but
only a PKCS #11 coprocessor can be used to avoid CPU cycles for FIPS
certified random content. Installations may wish to plan for CCA and/or
PKCS #11 coprocessor availability to avoid potentially excessive CPU
cycles being exhausted on random number content generation.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>The system issues informational message ICH408I
that indicates insufficient authorization might be issued to the console.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If your installation uses ICSF, you should
ensure that any RACF user ID that will start SSL applications can
access the CSFRNG callable service. This includes the SSL started
task (GSKSRVR), and the <strong>gskkyman</strong> and <strong>gsktrace</strong> utilities.</p>
<ol type="1">
<li>Determine if the CSFSERV class is active. If active, this class
restricts access to the ICSF programming interface. If it is not active,
access to the ICSF programming interface (and specifically the CSFRNG
callable service) is unrestricted. No configuration is necessary.
  

<p>To determine which RACF classes are currently active, enter the
SETROPTS command with the LIST parameter specified: </p>
<pre class="xmp"><code>SETROPTS LIST</code></pre></li>
<li>If the SETROPTS LIST command shows that the CSFSERV class is active,
identify the profile that covers the CSFRNG resource. This could be
a discrete profile named CSFRNG or, if generic profile checking is
activated, a generic profile.   

<p>To determine if a profile has been
defined to protect the CSFRNG resource, enter the following RLIST
command: </p>
<pre class="xmp"><code>RLIST CSFSERV CSFRNG</code></pre>When you enter
this command, RACF lists information for the discrete resource profile
CSFRNG.  If there is no matching discrete profile, RACF will list
the generic profile that most closely matches the resource name.</li>
<li>If the RLIST command output revealed that there is a discrete
or generic profile defined that covers the CSFRNG resource, examine
the command output to ensure that all RACF user IDs that may start
System SSL applications have at least READ access to the CSFRNG resource.
If necessary, use the PERMIT command to give the appropriate users
or groups access. For example, if a discrete profile CSFRNG exists,
the following command would give user BAILEY access.   
<pre class="xmp"><code>PERMIT CSFRNG CLASS(CSFSERV) ID(BAILEY) ACCESS(READ)</code></pre> If
you do make any changes, refresh the in-storage RACF profiles for
the CSFSERV class:   
<pre class="xmp"><code>SETROPTS RACLIST(CSFSERV) REFRESH</code></pre></li></ol>
<p><strong>Reference information</strong>: For additional information about
System SSL's use of ICSF callable services, refer to <cite>z/OS Cryptographic Services System SSL Programming, SC14-7495</cite>.</p>
<p>For additional information on the ICSF installation options file,
refer to <cite>z/OS Cryptographic Services ICSF System Programmer&amp;apos;s Guide</cite>.</p>
<p>For additional information about ICSF's CSFSERV resource class
and the Installation Option Display panel, refer to <cite>z/OS Cryptographic Services ICSF Administrator&amp;apos;s Guide, SA22-7521</cite>.</p>
<h3 id="e0z3m100-gen31">Cryptographic Services actions to perform after the first IPL
of z/OS V2R1</h3>
<p>This topic describes Cryptographic Services migration actions that
you can perform only after you have IPLed z/OS V2R1. You need a running z/OS V2R1 system
to perform these actions.<a id="idx375"></a><a id="idx376"></a><a id="idx377"></a><a id="idx378"></a><a id="idx379"></a><a id="idx380"></a></p>
<p>None.</p>
<h2 id="af1dfsm">DFSMS migration
actions</h2>
<p>This topic describes migration actions for base element DFSMSdfp and
optional features DFSMSdss, DFSMShsm, DFSMSrmm,
and DFSMStvs.</p>
<h3 id="e0z3m100-gen32">DFSMS actions
to perform before installing z/OS V2R1</h3><a id="idx381"></a>
<p>This topic describes DFSMS migration actions that you can perform
on your current (old) system. You do not need thez/OS V2R1 level of
code to make these changes, and the changes do not require the z/OS
V2R1 level of code to run once they are made.</p>
<p><a href="e0z3m100.htm#ax3eisc1">DFSMSdfp:
Back up SMS control data sets</a></p>
<p><a href="e0z3m100.htm#dt2mg366">DFSMSdfp: Obtain descriptive text in messages for Open/Close/End
of Volume ABENDs</a></p>
<p><a href="e0z3m100.htm#dfsmssms">DFSMS: Remove SMA fields from the SMS storage group construct
IGDSGD ands from ISMF panels</a></p>
<h4 id="ax3eisc">DFSMSdfp:
Back up SMS control data sets</h4><a id="idx382"></a><a id="idx383"></a><a id="idx384"></a><a id="idx385"></a>
<p>[[[[ Technical contact: Stevan Steve Allen/San
Jose/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: In a multisystem Storage Management
Subsystem (SMS) complex, operating systems share a common set of SMS
classes, groups, ACS routines, and a configuration base, which make
up the storage management policy for the complex. This storage management
policy is maintained in a source control data set (SCDS). When this
policy is activated for SMS, the bound policy is maintained in processor
storage and on DASD in an active control data set (ACDS). Systems
in the complex communicate SMS information through a common communications
data set (COMMDS).</p>
<p><a id="idx386"></a><a id="idx387"></a><a id="idx388"></a><a id="idx389"></a><a id="idx390"></a><a id="idx391"></a><a id="idx392"></a><a id="idx393"></a><a id="idx394"></a><a id="idx395"></a>It is recommended that to successfully share SMS control data sets
in a multisystem environment where there are mixed levels of DFSMS, you update,
translate, validate, and activate SMS policies on the system with
the latest level of DFSMS.
When an earlier control data set is to be updated or activated, the
control data set is formatted by the later-level system. The shared
SMS control blocks reflect the new, rather than the previous, lengths
and control information.</p>
<p>For fallback, IBM recommends
restoring SMS control data sets from backups taken on the fallback
release.</p>
<p>Editing a policy on an earlier system could invalidate unused control
information and prevent the control data set from being accessed by
a later system.  A warning message is provided before a policy can
be changed on an earlier system. ACS routines may need to be updated
and translated so to not reference policy items not known to the earlier
system.</p>
<p>Remember, you risk policy activation failures if SCDS changes are
not validated using the latest-level system in a sysplex.</p>
<table id="wq235" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to ensure data integrity.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>Install the PTFs in <a href="e0z3m100.htm#coxptfs">Install coexistence and fallback PTFs</a> if
they are not already installed.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Do the following on your <span>pre-z/OS V2R1</span> systems:</p>
<ol type="1">
<li>Back up SMS control data sets according to established procedures
in the event that fallback is required. The control data set format
is VSAM linear.</li>
<li>Install all coexistence PTFs in <a href="e0z3m100.htm#coxptfs">Install coexistence and fallback PTFs</a>.</li></ol>
<p>In addition, if you modified and activated a higher-level
policy on a <span>pre-z/OS V2R1</span> system, do the
following to ensure that the ACDS can be accessed on z/OS V2R1 and
that the SMS control block reflect the new lengths and control information:</p>
<ol type="1">
<li> On the <span>pre-z/OS V2R1</span> system, save the
active ACDS as an SCDS with the SETSMS SAVESCDS command.</li>
<li>On z/OS V2R1, update, translate, validate, and activate
the saved SMS policy.</li></ol>
<p><strong>Reference information</strong>: 

</p>
<ul>
<li><cite>z/OS DFSMS Implementing System-Managed Storage</cite></li>
<li><cite>z/OS DFSMSdfp Storage Administration</cite></li></ul>
<h4 id="dt2mg366">DFSMSdfp: Obtain descriptive text in messages for Open/Close/End
of Volume ABENDs</h4><a id="idx396"></a>
<p></p>
<p><strong>Description</strong>: z/OS V1R13 DFSMSdfp introduces a new
function that externalizes in the IECxxxx message for OPEN, CLOSE,
end-of-Volume determinant ABENDs,  the descriptive text from the message
documentation manuals.  This function is enabled by specifying in
the MPFLST<em>xx</em> PARMLIB member: MSGOPTION VERBOSE(x), where <em>x</em> is
either Y or N, with N as the default.  If you were using OCE_ABEND_DESCRIP
in DEVSUPxx to obtain this descriptive text before OA37505 was installed,
then you need to convert to using MPFLSTxx after OA37505 is installed.</p>
<div>
<div class="note-noindent" id="wq238">
<span class="notetitle">Note:</span> <span class="notebody">Beginning in z/OS V2R1, or after applying the PTF for
APAR OA37505 in z/OS V1R13, the VERBOSE message is displayed only
in the JOBLOG.</span></div></div>
<p>In addition, all OPEN, CLOSE and End-of-volume ABEND messages
are issued using a Message Buffer Manager service, whether or not
the new VERBOSE message function is enabled. One change this introduces
is that the IECxxxx portion of the message always appears as a multi-line
WTO message. Automated operation services that parse these messages
may be affected.</p>
<table id="wq239" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdfp</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13 with PTF for APAR OA37505 applied.</td>
</tr>
<tr id="xfmtmark-gen1__d5">
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 without PTF for APAR OA37505 applied,
and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if any of these conditions are true:

<ul>
<li>You have z/OS V1R13 without APAR OA37505 installed, and are using
the OCE_ABEND_DESCRIP function in DEVSUPxx for verbose messages.</li>
<li>If you have automation or programs that depend upon the type (single-line
WTO as opposed to multi-line WTO) of the IECxxxx message.</li></ul></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>Remove OCE_ABEND_DESCRIP from DEVSUPxx parmlib
member; otherwise you receive the following informational message
at IPL time: 
<pre class="xmp"><code>IEA253I DEVSUP OCE_ABEND_DESCRIP 
NO LONGER HAS AFFECT. USE MPFLSTXX MEMBER </code></pre></td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If
you were using DEVSUP<em>xx</em> to obtain the ABEND descriptive text
before OA37505 was installed, then you need to convert to using MPFLST<em>xx</em> to
obtain this information after OA37505 is installed. In the MPFLST<em>xx</em> PARMLIB
member, specify MSGOPTION VERBOSE(Y) to enable display of the descriptive
text.</p>
<p>Because OPEN, CLOSE and end-of-volume ABEND messages now include
the IECxxxx portion of the message as a multi-line WTO message, any
automated operation services that parse these messages might need
to be adjusted. Examine such automated operation services and adjust
them to handle the new format as needed.</p>
<p>Here is an example of the output message you receive after you
install APAR OA37505: </p>
<pre class="xmp"><code>JOB00608 00000090 IEC141I 013-18,IGG0191B,IBMUSER9,S01,SYSUT1,5901,ZR1DT1, 651
651 00000090 SYS1.SAMPLIB(ZZZZZZZZ) </code></pre>
<p><strong>Reference information:</strong> For
details about using the VERBOSE option in MPFLSTxx, see <cite>z/OS MVS Initialization and Tuning Guide</cite>.</p>
<h4 id="dfsmssms">DFSMS: Remove SMA fields from the SMS storage group construct
IGDSGD ands from ISMF panels</h4><a id="idx397"></a><a id="idx398"></a>
<p>[[[[ Contributing writer: /IBM@IBMUS ]]]]
[[[[ Original technical contact: ]]]]</p>
<p>To be updated in the next review.</p>
<p><strong>Description</strong>: Before z/OS V1R13, new SMS storage group constructs
were created in DFSMS in support of the z/OSMF DASD Management task.
Starting with z/OS V1R13 the DASD Management task has been removed
from z/OSMF, and these fields (known as SMA attributes) will be removed
from the storage group construct (IGDSGD). The fields have been removed
from ISMF panels, Naviquest APIs, and DCOLLECT records.</p>
<table id="wq240" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMS</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13 with APAR PM40869 applied. See Software
Announcement 211-252 (RFA56143).</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS z/OS V1R13 and z/OS V1R12 without APAR
PM40869 applied.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td align="left">Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you parse the new attributes in DCOLLECT
output or view/update them through NAVIQUEST. IBM might redefine these
storage group and DCOLLECT fields in a future release.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>z/OS V1R13</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ol type="1">
<li>Look for the following storage group attributes (known as SMA
attributes) as defined by the IGDSGD macro. 

<ul>
<li>SGDMANTH</li>
<li>SGDMASUG</li>
<li>SGDMAMAX</li>
<li>SGDMAVSZ</li>
<li>SGDMAVTC</li>
<li>SGDMARSP</li>
<li>SGDMAVNM</li></ul></li>
<li>Identify the following Naviquest functions associated with the
SMA attributes identified in step 1.: 

<ul>
<li>ACBQBAJ2 - clist for Define/Alter/Display pool storage group</li>
<li>ACBQBAJG - clist for Pool Storage Group Display ACBJBAJ2 -</li>
<li>Sample JCL for Pool storage group define/alter/display</li>
<li></li></ul></li>
<li>Use the IDCDOUT mapping macro to map the following DCOLLECT fields
and remove the references to those fields: 

<ul>
<li>DSGFSMA</li>
<li>DSGMANTH</li>
<li>DSGMASUG</li>
<li>DSGMAMAX</li>
<li>DSGMAVSZ</li>
<li>DSGMAVTC</li>
<li>DSGMARSP</li>
<li>DSGMAVNM</li></ul></li></ol>
<p><strong>Reference information:</strong> For information about the SMA attributes,
see the following:
</p>
<ul>
<li><cite>z/OS DFSMS Using the New Functions</cite></li>
<li><cite>z/OS DFSMSdfp Storage Administration</cite></li>
<li><cite>z/OS DFSMS Access Method Services Commands</cite></li></ul>
<h3 id="e0z3m100-gen33">DFSMS actions
to perform before the first IPL of z/OS V2R1</h3>
<p>This topic describes DFSMS migration actions that you can perform
after you have installed z/OS V2R1 but before the first time you IPL.
These actions might require the z/OS V2R1 level of code to be installed
but do not require it to be active.</p>
<p><a href="e0z3m100.htm#af32b1">DFSMSdfp:
Ensure that the Language
Environment runtime library is available for DLLs******TO BE
REMOVED PER DISCUSSION ON EREVIEW**********</a></p>
<p><a href="e0z3m100.htm#af32e">DFSMSdfp:
Update SYS1.IMAGELIB</a></p>
<p><a href="e0z3m100.htm#iebcopy1">Examine and update program calls to IEBCOPY</a></p>
<p><a href="e0z3m100.htm#af3d">DFSMSdss:
Build the IPLable stand-alone DFSMSdss image</a></p>
<p><a href="e0z3m100.htm#hsmlist1">DFSMShsm: Update applications that depend on LIST command output</a></p>
<p><a href="e0z3m100.htm#dt2mg377">DFSMSrmm: Check how you control your RACF tape profile processing</a></p>
<h4 id="af32b">DFSMSdfp:
Ensure that the Language
Environment runtime library is available for DLLs</h4><a id="idx399"></a><a id="idx400"></a><a id="idx401"></a><a id="idx402"></a><a id="idx403"></a><a id="idx404"></a>
<p><strong>Description</strong>: Language Environment provides
common services and language-specific routines in a single runtime
environment. You can use Language Environment to build and use dynamic link
libraries (DLLs) for applications.<a id="idx405"></a><a id="idx406"></a></p>
<table id="wq242" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your installation builds or references
DLLs.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If your installation builds
or references DLLs, either you must set up the system link list to
refer to the Language
Environment runtime libraries (SCEERUN and SCEERUN2), or each
job that creates or uses a DLL must include a STEPLIB DD statement
referencing these libraries.</p>
<p><strong>Reference information</strong>: 

</p>
<ul>
<li><cite>z/OS Language Environment Runtime Application Migration Guide</cite></li>
<li><cite>z/OS Language Environment Customization</cite></li>
<li><cite>z/OS Language Environment Programming Guide</cite></li></ul>
<h4 id="af32e">DFSMSdfp:
Update SYS1.IMAGELIB</h4>
<p><strong>Description</strong>: If you use page mode printers
such as the IBM 3800 or the IBM 3900 running in line mode (not
page mode), you must install library character sets, graphic character
modification modules, and character arrangement tables in SYS1.IMAGELIB. <a id="idx407"></a><a id="idx408"></a><a id="idx409"></a>
This migration action does not
apply if you are using IBM 3900
printers that are driven by PSF.</p>
<table id="wq243" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are not using your old SYS1.IMAGELIB,
you are installing with ServerPac or SystemPac, and you are using line mode printers
such as the 3800 or 3900.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>IBM 3800
or 3900 printers.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Run the LCSBLD1 job from the samplib data set to create character
sets, graphic character modification modules, and character arrangement
tables in SYS1.IMAGELIB.</li>
<li>Copy customized or locally-written FCBs and UCS images from your
old system's SYS1.IMAGELIB data set to the new system's SYS1.IMAGELIB
data set.</li></ol>
<p><strong>Reference information</strong>: For information about
maintaining SYS1.IMAGELIB, see <cite>z/OS DFSMSdfp Advanced Services</cite>.</p>
<h4 id="iebcopy1">Examine and update program calls to IEBCOPY</h4><a id="idx410"></a>
<p>[[[[ Contributing writer: Paul F Gorgen/Poughkeepsie/IBM@IBMUS &gt;
]]]] [[[[ Technical contact: &lt;Example: Wayne Rhoten/San Jose/IBM@IBMUS &gt;
]]]]</p>
<p><strong>Description</strong>: Before z/OS V2R1, the IEBCOPY utility assumed
that calls from programs (not from JCL) that passed three parameters,
had the high order bit set on in the third word of the parameter list.
Starting in z/OS V2R1, IEBCOPY requires the high order bit to be on
in the third word of a parameter list; if that bit is not on, IEBCOPY
causes a failure. This change can affect your programs that call IEBCOPY,
requiring you to update them if needed. <a id="idx411"></a></p>
<p>Beginning in z/OS V2R1, the invoker of IEBCOPY will be
able to specify the exits by using the fourth parameter on the invocation.
The new fourth word in the IEBCOPY invocation parameter list has a
31-bit address of the user exit parameter list. This IEBCOPY user
exit routine enables a program to supply IEBCOPY control statements
instead of IEBCOPY reading control statements from SYSIN.</p>
<table id="wq245" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and DFSMS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have programs that pass
a parameter list of exactly three words to IEBCOPY and do not set
on the high order bit in the last word.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Examine calls from programs (not from JCL)
to IEBCOPY, to see whether any pass three parameters  without turning
on the high order bit in the last word.  If you have such programs,
revise them to turn on the high order bit of the last word of the
parameter list. If you are using the CALL, LINK or ATTACH macro, the
simplest way to do this is to add the VL parameter to CALL or VL=1
parameter to LINK or ATTACH.</p>
<p><strong>Reference information</strong>: For details about program calls to
IEBCOPY, see <cite>z/OS DFSMSdfp Utilities</cite>.</p>
<h4 id="af3d">DFSMSdss:
Build the IPLable stand-alone DFSMSdss image</h4>
<p>[[[[ Techical contact: Robert2 Gensler/Tucson/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: If you intend to use the Stand-Alone
Services provided by DFSMSdss, you must use the DFSMSdss BUILDSA
function to create the Stand-Alone Services IPL-capable core image. Starting
with z/OS V1R12, DFSMSdss now uses BSAM instead of EXCP to read from
and write to DFSMSdss dump data sets during DUMP, COPYDUMP, and RESTORE
operations. To migrate to this support, you must rebuild the IPL-able
core image for the Stand-Alone Services program. <a id="idx412"></a><a id="idx413"></a></p>
<p>If this migration
action is not performed, users of the DSS standalone restore will
not be able to restore backups on tape created with greater than 65520
byte blocks. Message ADRY3530I SEQUENCE ERROR ON RESTORE TAPE is issued
and the operation is terminated. Backups created with 65520 byte blocks
will restore as they did in z/OS V1R11.</p>
<table id="wq246" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMSdss.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you intend to use the Stand-Alone Services
provided by DFSMSdss.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>Stand-Alone Services supports the IBM 3494 TotalStorage Enterprise Automated Tape Library,
the IBM 3495 TotalStorage Enterprise
Automated Tape Library, and the IBM 3590 TotalStorage Enterprise
Tape Subsystem.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>Stand-Alone Services does not support the creation
of the core image on an SMS-managed volume.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>
<ul>
<li>To ensure that Stand-Alone Services is available when you run
from DASD, do not delete the SYS1.ADR.SAIPLD.Vvolser data set or move
it to another volume.</li>
<li>If you IPL from DASD and later change the volume serial number,
you must rerun the BUILDSA function to create a new core image data
set with the new volume serial number in the name.</li></ul></td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Prepare for Stand-Alone Services by creating a Stand-Alone Services
IPLable core image with the BUILDSA command. With the BUILDSA command
you can specify the device (card reader, tape drive, or DASD volume)
from which Stand-Alone Services will be IPLed. You can also specify
the operator console to be used for Stand-Alone Services. 


<p>The BUILDSA
function builds the IPLable core image under the current operating
system and determines a record size based on whether the IPL is from
card, tape, or DASD.</p></li>
<li>Use RACF or another external
security system to protect the SYS1.ADR.SAIPLD.V<span class="synph"><span class="var">volser</span></span> data
set and the Stand-Alone Services modules.</li>
<li>If you have not done so already, make a backup copy of your system
that can be restored by this function. For information about backing
up volumes, see <cite>z/OS DFSMSdss Storage Administration</cite>.

<div>
<div class="note-noindent" id="wq248">
<span class="notetitle">Note:</span> <span class="notebody">Message  ADRY3530I SEQUENCE ERROR ON RESTORE TAPE might
be issued with operation terminated if a user tries to restore a back
up that was created with a block size greater than 65520 bytes, using
the DSS stand-alone restore program from z/OS V1R11.</span></div></div></li></ol>
<p><strong>Reference information</strong>: For more information,
see <cite>z/OS DFSMSdfp Storage Administration</cite>.</p>
<h4 id="hsmlist">DFSMShsm: Update applications that depend on LIST command output</h4>
<p>[[[[ Contributing writer: Bill Keller]]]]
[[[[ Technical contact: Jason R. Luurs]]]]</p>
<p><strong>Description</strong>: The output of the LIST DUMPCLASS command now
includes the value of the RECOVERRESET parameter. 	RECOVERRESET is
a new parameter of the DEFINE DUMPCLASS command that specifies whether
or not the data-set-changed indicator in the VTOC entry is reset for
all data sets that are restored during full volume recover processing.<a id="idx414"></a><a id="idx415"></a></p>
<table id="wq249" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMShsm</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your application depends on the output
of the LIST DUMPCLASS command.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Update applications that depend on the output
of the LIST DUMPCLASS command to accommodate the new value for RECOVERRESET.</p>
<p><strong>Reference information</strong>: For details about the LIST DUMPCLASS
output, refer to <cite>z/OS DFSMShsm Storage Administration</cite>.</p>
<h4 id="dt2mg377">DFSMSrmm: Check how you control your RACF tape profile processing</h4><a id="idx416"></a>
<p></p>
<p><strong>Description</strong>: Since z/OS V1R8 DFSMSrmm supports the TAPEAUTHDSN
parameter in the DEVSUPxx (device support) parmlib member; however,
this support has required enhancements in z/OS V2R1 to be properly
implemented.</p>
<p> Before z/OS V2R1, TAPEAUTHDSN=YES RMM performed tape authorization
checks in the DATASET class against discrete profiles through RACF.</p>
<p>TAPEAUTHDSN=YES DFSMSrmm performed tape authorization checks  in
the DATASET class with DSTYPE=T to indicate to RACF that the check
was for data sets on tape volumes and that a RACF check for authority
to a discrete data set profile had been performed.  With z/OS V2R1
DFSMSrmm correctly supports option TAPEAUTHDSN according to the documentation
in <cite>zOS MVS Initialization and Tuning Guide</cite> and in <cite>z/OS
DFSMSrmm Implementation and Customization Guide</cite>.  If TAPEAUTHDSN=YES
is set, DFSMSrmm now performs authorization checking without DSTYPE=T.
The RACROUTE is issued in the DATASET class as if for a DASD data
set.</p>
<p>You had a working setup ("TAPEAUTHDSN=YES with discrete profiles"
or "TAPEAUTHDSN=NO with generic profiles" If you want to continue
with existing setting "TAPEAUTHDSN=YES". then you need to create generic
profiles now. If you want to continue with existing generic profiles,
you need to set "TAPEAUTHDSN=NO" now.</p>
<table id="wq250" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSrmm</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes,
if you have set up the RACF implementation.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Check
to determine if you use the TAPEAUTHDSN=YES option in your DEVSUPxx
parmlib member. If the option is implemented, based on your overall
RACF and DFSMSrmm configuration that you use with discrete data set
profiles, you must prepare for a change in processing after you IPL
V2R1:
</p>
<ol type="1">
<li>If you want to continue using your existing data set profiles
(generic or discrete), you need the exchange the current TAPEAUTHDSN
settings.  TAPEAUTHDSN=YES will now make use of generic profiles;
TAPEAUTHDSN=NO will now make us of discrete profiles."</li></ol>
<p>.</p>
<p><strong>Reference information:</strong> See
 "Recommendations for using RACF tape profile processing" in <em>z/OS
DFSMSrmm Implementation and Customization Guide</em>.  See "Enhanced
security for tape data sets" in <em>zOS MVS Initialization and Tuning
Guid</em>e.</p>
<h3 id="e0z3m100-gen34">DFSMS actions
to perform after the first IPL of z/OS V2R1</h3>
<p>This topic describes DFSMS migration actions that you can perform
only after you have IPLed z/OS V2R1. You need a running z/OS V2R1
system to perform these actions.</p>
<p><a href="e0z3m100.htm#bindgra">DFSMSdfp:
Run OAM DB2 BIND jobs</a></p>
<p><a href="e0z3m100.htm#dfpsms1">DFSMSdfp: Configure clusters and storage groups for SMS volume
selection</a></p>
<p><a href="e0z3m100.htm#voltrack1">DFSMSdss: Accommodate new default behavior for full-volume
and track restore operations</a></p>
<p><a href="e0z3m100.htm#dfshsmds">DFSMShsm: Prepare to handle DFSMShsm changes to the key of
some of its CDS records, backup data set name format, and migrated
data sets</a></p>
<h4 id="bindgra">DFSMSdfp:
Run OAM DB2 BIND jobs</h4>
<p>[[[[ Contributing writer: James E Becker/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Sherrie Niederbrach/Tucson/IBM@IBMUS
]]]] [[[[ Technical contact: Brian Corkill/Tucson/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: When migrating to any new release of z/OS,
you must run OAM DB2 BIND jobs
if you are using OAM for object support. The BIND jobs update DB2 with new OAM DB2 code.</p>
<table id="wq252" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx417"></a><a id="idx418"></a><a id="idx419"></a><strong>Element
or feature</strong>:</td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use OAM object support.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Run the BIND jobs appropriate to your installation:</p>
<ol type="1">
<li>Update and execute the samplib job CBRPBIND (OAM DB2 Bind Package Job).</li>
<li>Do one of the following: 

<ul>
<li>If your installation starts OAM, uses the file system sublevel
or optical or tape devices, or uses the OAM storage management component
(OSMC), do the following: 

<ul>
<li>Update and execute samplib job CBRABIND (OAM DB2 Application Plan Bind for LCS and OSR).</li>
<li>Update and execute samplib job CBRHBIND (OAM DB2 Application Plan Bind for OSMC).</li></ul></li>
<li>If your installation does not start OAM, use the file system sublevel
or optical or tape devices, or use OSMC, update and execute samplib
job CBRIBIND (OAM DB2 Application Plan Bind for OSR only).</li></ul></li>
<li>For more information, see the topic "Migrating, Installing, and
Customizing OAM" in <cite>z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Object Support</cite>.</li></ol>
<p>  </p>
<div>
<div class="note-noindent" id="wq254">
<span class="notetitle">Note:</span> <span class="notebody">If you choose to edit a previous version of an OAM BIND
job, you must incorporate any new changes as described in the header
of each samplib OAM BIND job.</span></div></div>
<p><strong>Reference information</strong>: For more information about OAM, see <cite>z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Object Support</cite>.</p>
<h4 id="dfpsms">DFSMSdfp: Configure clusters and storage groups for SMS volume
selection</h4><a id="idx420"></a><a id="idx421"></a><a id="idx422"></a><a id="idx423"></a><a id="idx424"></a><a id="idx425"></a>
<p>[[[[ Contributing writer: Bill Keller]]]]
[[[[ Technical contact: Victor Liang]]]]</p>
<p><strong>Description</strong>: Before z/OS V2R1, when allocating or extending
a multi-volume data set, SMS preferred the candidate volumes in the
same storage facility image (SFI) if the storage class accessibility
attribute was set to CONTINUOUS or CONTINUOUS PREFERRED. With z/OS
V2R1, SMS prefers volumes that are in the same cluster. Similarly,
when allocating the target data set for the data set fast replication
function, SMS now prefers volumes that are in the same cluster as
the source data set. In both cases, if it is not possible to honor
the preference of volumes in the cluster, SMS reverts to preferring
volumes in the same SFI. If you wish SMS to select volumes in the
same cluster, you should configure your clusters accordingly.<a id="idx426"></a></p>
<p>Before z/OS V2R1, when allocating a striped data set, SMS allocated
the stripes across separate logical control units (LCUs). With z/OS
V2R1, SMS attempts to allocate the stripes across separate extent
pools. If this is not possible, SMS continues to allocate the stripes
across LCUs. If you wish SMS to separate the stripes across extent
pools, you should configure your storage groups accordingly.</p>
<table id="wq255" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended for optimum efficiency of
data set fast replication and for the most uniform performance with
striped data sets.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If you wish SMS to select volumes in the
same cluster, configure your clusters accordingly.</p>
<p>For striped data sets, if you wish SMS to separate the stripes
across extent pools, configure your storage groups accordingly.</p>
<p><strong>Reference information</strong>: For details about SMS volume selection
and about striped data sets, refer to<cite>z/OS DFSMSdfp Storage Administration</cite>.</p>
<h4 id="voltrack">DFSMSdss: Accommodate new default behavior for full-volume
and track restore operations</h4>
<p>[[[[ Contributing writer: Bill Keller]]]]
[[[[ Technical contact: Jason R. Luurs]]]]</p>
<p><strong>Description</strong>: The data-set-changed indicator (DS1DSCHA) in
the VTOC indicates whether or not the data set has changed since its
last backup.  Before z/OS V2R1, during a full-volume restore operation,
DFSMSdss unconditionally reset (turned off) the data-set-changed indicator
for each data set restored to the target volume. During a tracks restore
operation, if any VTOC track was restored, DFSMSdss might reset the
data-set-changed indicator for all data sets on the volume. <span>This
applies to all VSAM and non-VSAM data sets and all SMS and non-SMS
data sets. </span><a id="idx427"></a><a id="idx428"></a></p>
<p>With z/OS V2R1, the default behavior for full-volume and tracks
restore operations has changed. By default, DFSMSdss now resets the
data-set-changed indicator only if the RESET keyword was specified
on the DUMP command. Along with this change, a RESET keyword has been
added to the RESTORE FULL and RESTORE TRACKS commands, which allows
you to specify whether the data-set-changed indicator is to be reset.
In addition, you can use the options installation exit routine, ADRUIXIT,
to control the resetting of the data-set-changed indicator.</p>
<p>You can use RESET on the RESTORE command for any FULL
or TRACKS dump taken with V2R1, or any previous releases. RESET(YES)
and RESET(NO) will work as expected. However, RESET(DUMP) will act
as RESET(NO) because there is no way to determine if the RESET keyword
was specified at DUMP time on a down-level dump. The new RESET(DUMP)
functionality is only available in V2R1.</p>
<p>Note that the default behavior for DFSMSdss DUMP is unchanged
when DFSMShsm invokes DFSMSdss to perform a full volume restore. By
default, DFSMShsm will pass RESET(YES) to DFSMSdss. The other parameters
might be specified through the DEFINE DUMPCLASS command.</p>
<table id="wq256" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMSdss.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want DFSMSdss to unconditionally
reset the data-set-changed indicator during full-volume and tracks
restore operations.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>The new default behavior is not in effect with
dumps taken before z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: To obtain the behavior in previous releases
to allow DFSMSdss to unconditionally reset the data-set-changed indicator
during full-volume and tracks restore operations, use RESET(YES) with
the RESTORE FULL and RESTORE TRACKS commands. The other options for
the RESET keyword are:  
</p>
<dl class="parml">
<dt class="bold">NO</dt>
<dd>DFSMSdss does not alter the DS1DSCHA values. Each DS1DSCHA represents
the value the data sets had at the time the dump was taken.
</dd>
<dt class="bold">DUMP</dt>
<dd>DFSMSdss resets the data-set-changed indicator (DS1DSCHA=OFF)
only if the RESET keyword was specified on the DUMP command.  This
is the default.
</dd>
</dl>
<p>You can also use the options installation exit routine ADRUIXIT
or API programs to override the behavior. The ADRUFO parameter list
contains these bits in the UFO8FLGS structure: 
</p>
<dl class="parml">
<dt class="bold">UFO8RESY</dt>
<dd>Corresponds to RESET(YES)
</dd>
<dt class="bold">UFO8RESN</dt>
<dd>Corresponds to RESET(NO)
</dd>
<dt class="bold">UFO8RESD</dt>
<dd>Corresponds to RESET(DUMP).
</dd>
</dl>
<div>
<div class="note-noindent" id="wq257">
<span class="notetitle">Note:</span> <span class="notebody"> The default behavior is unchanged when DFSMShsm invokes
DFSMSdss to perform a full volume restore. By default, DFSMShsm will
pass RESET(YES) to DFSMSdss. You can specify the other parameters
through the DEFINE DUMPCLASS command.</span></div></div>
<p><strong>Reference information</strong>: For details about the RESTORE command,
see <cite>z/OS DFSMSdss Storage Administration</cite>.
For details about the installation exit, see <cite>z/OS DFSMS Installation Exits</cite>.</p>
<h4 id="dfshsmds">DFSMShsm: Prepare to handle DFSMShsm changes to the key of
some of its CDS records, backup data set name format, and migrated
data sets</h4><a id="idx429"></a>
<p>[[[[ Contributing writer: Sonja Moore/Durham/Contr/IBM@IBMUS
]]]] [[[[ Original technical contact: Greg Callis/Raleigh/IBM@IBMUS
]]]]TBD</p>
<p><strong>Description</strong>: As of z/OS V2R1 DFSMShsm is changing the key
of some of its CDS records, the backup data set name format and migrated
data sets.</p>
<p>When HSM creates its CDS records and the backup or migration target
dataset name (HSMDSN), it generates the name using the first two qualifiers
of the source DS along with the time and date. The cds records affected
are the MCC, MCM, MCA, and MCO.</p>
<p>As of z/OS V2R1 the HSM data set name format is: </p>
<pre class="xmp"><code>prefix.func.Tcccchh.user1.user2.Xyddd</code></pre><p class="indatacontent"> The
3rd qualifier is now <samp class="xph">Tcccchh</samp>, where '<samp class="xph">cccc</samp>'
is hundredths of seconds from the beginning of the hour converted
to four alphabetic characters.</p>
<table id="wq258" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMShsm</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1. APAR OA38729????????</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td align="left">After first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if DFSMShsm data set creation
collision (<samp class="xph">hsmdsn</samp> ) occurs frequently as this change
can help reduce some processing time.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>ZOSMIGV2R1_CS_GATEWAY can help you determine
if you are using any GATEWAY statements in your TCP/IP profile.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: For any program/tool that inspects the HSMDSN
time qualifier, use the pseudo code provided in <cite>z/OS DFSMSdfp Storage Administration</cite> to
decode the time portion of the HSMDSN.</p>
<p><strong>Reference information:</strong> <cite>z/OS DFSMSdfp Storage Administration</cite>.</p>
<h2 id="dfsomig">DFSORT migration
actions</h2>
<p>This topic describes migration actions for optional feature DFSORT.</p>
<h3 id="e0z3m100-gen35">DFSORT actions
to perform before installing z/OS V2R1</h3><a id="idx430"></a>
<p>This topic describes DFSORT migration actions that you can perform
on your current (old) system. You do not need the z/OS V2R1 level
of code to make these changes, and the changes do not require the
z/OS V2R1 level of code to run once they are made.</p>
<p>None.</p>
<h3 id="e0z3m100-gen112">DFSORT actions
to perform before the first IPL of z/OS V2R1</h3>
<p>This topic describes DFSORT migration actions that you can perform
after you have installed z/OS V2R1 but before the first time you IPL.
These actions might require the z/OS V2R1
level of code to be installed but do not require it to be active.</p>
<p><a href="e0z3m100.htm#dfsomsg1">Update automation for changed DFSORT messages</a></p>
<p><a href="e0z3m100.htm#tunedfsort1">Use TUNE=OLD option to prevent balancing resources for concurrent
sort applications</a></p>
<p><a href="e0z3m100.htm#expold1">Use EXPOLD=MAX and EXPRES=0 to prevent changed defaults</a></p>
<h4 id="dfsomsg1">Update automation for changed DFSORT messages</h4><a id="idx431"></a><a id="idx432"></a><a id="idx433"></a><a id="idx434"></a><a id="idx435"></a><a id="idx436"></a>
<p>[[[[ Contributing writer: James E Becker/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Vicky Vezinaw/San Jose/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: In z/OS V2R1,
the text for some DFSORT messages
(ICE<span class="synph"><span class="var">xxxx</span></span>) is changed. Text and insert fields
have been added, changed, or removed in the messages listed below
in &quot;Steps to take&quot;. These changes can affect automation programs
that examine the text of the messages.</p>
<table id="wq259" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSORT.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have automation routines that examine
the message text of the messages listed below in &quot;Steps to take&quot;.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Update your automation to handle the following DFSORT message
changes: 
</p>
<ul>
<li></li>
<li>The product number has changed from &quot;5694-A01&quot; to &quot;5650-ZOS&quot;,
and the release level has changed from "V1R12" to "V2R1 ", in message
ICE000I.</li>
<li>The following new messages have been added:   

<ul>
<li>ICE290A</li>
<li>ICE291I</li></ul></li>
<li>Text and insert fields have been changed in the following messages
to provide new information:    

<ul>
<li>ICE083A</li>
<li>ICE118I</li>
<li>ICE141A</li>
<li>ICE236I</li>
<li>ICE285A</li>
<li>ICE997I</li></ul></li></ul>
<p><strong>Reference information</strong>: For details about the ICE messages,
see <cite>z/OS DFSORT Messages, Codes and Diagnosis Guide</cite>.</p>
<h4 id="tunedfsort1">Use TUNE=OLD option to prevent balancing resources for concurrent
sort applications</h4><a id="idx437"></a><a id="idx438"></a><a id="idx439"></a><a id="idx440"></a><a id="idx441"></a><a id="idx442"></a>
<p>[[[[ Technical contact: Frank Yaeger/San
Jose/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Beginning with z/OS V2R1, a new TUNE installation
default allows you to specify whether DFSORT should allocate storage
in increments with additional disk work space to minimize the risk
of failure, or to allocate all storage at initialization so disk work
space allocation can be reduced.  The IBM-supplied default for the
new TUNE installation option is TUNE=STOR which specifies allocation
of available central storage as needed in increments sized to balance
resource usage for concurrent sorts.  If you want DFSORT to allocate
available central storage using fixed sized increments, as in previous
releases, you can set TUNE=OLD.</p>
<p>TUNE has the following values:
</p>
<ul>
<li>STOR</li>
<li>DISK</li>
<li>DDYN</li>
<li>OLD</li></ul><a id="idx443"></a><a id="idx444"></a><a id="idx445"></a>
<table id="wq260" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSORT.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the default value TUNE=STOR is not acceptable.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>ICEPRMxx member(s) of PARMLIB can be shared
between systems running different releases of DFSORT. Any installation
options specified in the ICEPRMxx member that are only supported in
the newer release of DFSORT will be ignored on the system using the
lower release of DFSORT.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ul>
<li>Use ICEPRMxx members activated by a START ICEOPT started task
command to set the TUNE=OLD  option, as appropriate.</li>
<li>Alternatively, you can set TUNE=OLD with the previous (less preferred)
method of using the ICEMAC macro and usermods.</li></ul>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li> For details about the TUNE installation option, see <cite>z/OS DFSORT Installation and Customization</cite>.</li></ul>
<h4 id="expold1">Use EXPOLD=MAX and EXPRES=0 to prevent changed defaults</h4>
<p>[[[[ Technical contact: Frank Yaeger/San
Jose/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Beginning with z/OS V2R1, IBM-supplied defaults
have been changed to EXPOLD=50% (from EXPOLD=MAX) and to EXPRES=10%
(from EXPRES=0). If you want DFSORT to use the old defaults, as in
previous releases, you can set EXPOLD=MAX and EXPRES=0.<a id="idx446"></a><a id="idx447"></a><a id="idx448"></a><a id="idx449"></a></p>
<table id="wq261" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSORT.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the new defaults are not acceptable.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ul>
<li>Use ICEPRMxx members activated by a START ICEOPT started task
command to set the EXPOLD=MAX or EXPRES=0 options, as appropriate.</li>
<li>Alternatively, you can set EXPOLD=MAX or EXPRES=0 with the previous
(less preferred) method of using the ICEMAC macro and usermods.</li></ul>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li> For details about the EXPOLD and EXPRES installation options,
see <cite>z/OS DFSORT Installation and Customization</cite>.</li></ul>
<h3 id="e0z3m100-gen37">DFSORT actions
to perform after the first IPL of z/OS V1R13</h3>
<p>This topic describes DFSORT migration actions that you can perform
only after you have IPLed z/OS V2R1. You need a running z/OS V2R1
system to perform these actions.</p>
<h2 id="dfsmiga">Distributed File Service migration actions</h2>
<p>This topic describes migration actions for base element Distributed
File Service.</p>
<h3 id="e0z3m100-gen38">Distributed File Service actions to perform before installing
z/OS V2R1</h3><a id="idx450"></a>
<p>This topic describes Distributed File Service migration actions
that you can perform on your current (old) system. You do not need
the z/OS V2R1 level of code to make these changes, and the changes
do not require the z/OS V2R1 level of code to run once they are made.<a id="idx451"></a><a id="idx452"></a><a id="idx453"></a><a id="idx454"></a></p>
<p><a href="e0z3m100.htm#remclone1">Remove usage of zFS clone function</a></p>
<h4 id="remclone">Remove usage of zFS clone function</h4><a id="idx455"></a><a id="idx456"></a><a id="idx457"></a><a id="idx458"></a><a id="idx459"></a><a id="idx460"></a>
<p>[[[[ Contributing writer: Nancy A Lewallen/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: James Showalter/Endicott/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Beginning with z/OS V2R1, the zFS clone function
is no longer supported.<a id="idx461"></a><a id="idx462"></a></p>
<table id="wq262" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>z/OS Distributed File Service</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are using or have used the zFS clone
function.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>If any system earlier than z/OS V2R1 mounts
a zFS aggregate that contains a .bak (clone) file system in a shared
file system environment, any catch-up mounts on a V2R1 system fail
and z/OS UNIX function ships from the V2R1 system to the z/OS UNIX
owning system.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Determine whether you have any .bak file
systems. You can do this by issuing a command like the following: </p>
<pre class="xmp"><code>zfsadm lsfs | grep .bak</code></pre><p class="indatacontent"> You
might see results as in this example: </p>
<pre class="xmp"><code>PLEX.JMS.AGG1.bak (Not Mounted) 458 K alloc 458 K quota On-line 
PLEX.JMS.AGG2.bak (Not Mounted) 26 K alloc 26 K quota On-line</code></pre><p class="indatacontent"> This
example shows that there are two zFS aggregates that contain a .bak
file system - PLEX.JMS.AGG1 and PLEX.JMS.AGG2. In this case, unmount
the .bak file systems (if they are mounted) and delete each .bak file
system from the aggregate with a command similar to the following
example: </p>
<pre class="xmp"><code>zfsadm delete PLEX.JMS.AGG1.bak</code></pre><p class="indatacontent"> (Note
that the file system name is case-sensitive.) If the delete fails
because the file system was not found, it probably means that the
zFS aggregate is not attached. Attach it, delete the .bak file, and
detach the aggregate.</p>
<p>You should delete all .bak file systems before you bring zFS into
the shared file system environment or before you IPL the V2R1 system.
Minimally, you must ensure that no zFS aggregates that contain .bak
file systems are mounted.</p>
<p><strong>Reference information</strong>: For more information, see <cite>z/OS Distributed File Service zFS Administration</cite>.</p>
<h3 id="e0z3m100-gen39">Distributed File Service actions to perform before the first
IPL of z/OS V2R1</h3>
<p>This topic describes Distributed File Service migration actions
that you can perform after you have installed z/OS V2R1 but before
the first time you IPL. These actions might require the z/OS V2R1 level of code to be installed but
do not require it to be active.</p>
<p><a href="e0z3m100.htm#dt2mg398">Ensure that the zFS kernel is active when using the batch utility
ioeagfmt</a></p>
<h4 id="dt2mg398">Ensure that the zFS kernel is active when using the batch utility
ioeagfmt</h4><a id="idx463"></a>
<p></p>
<p><strong>Description</strong>: Before z/OS V2R1, the batch utility<strong><samp>ioeagfmt</samp></strong> did
not require that the zFS kernel be active. Starting in V2R1, <strong><samp>ioeagfmt</samp></strong> requires
that the zFS kernel be active.</p>
<table id="wq263" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>zFS</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you did not run <strong><samp>ioeagfmt</samp></strong> after
the kernel was initialized. However, it would be unusual not to have
zFS active when running <strong><samp>ioeagfmt</samp></strong>.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Look for vendor applications that might be
creating or submitting JCL containing <strong><samp>ioeagfmt</samp></strong> calls
that are run when the zFS kernel is not active. Run them when the
zFS kernel is active. If you are formatting file systems to be used
by another system, you should be setting the  <samp>-version</samp> parameter
on <strong><samp>ioeagfmt</samp></strong> because the local zFS kernel would
not have the information for a remote zFS system. You can also use
the <strong><samp>ioefsutl</samp></strong> program to achieve the same results.</p>
<p><strong>Reference information:</strong></p>
<h3 id="e0z3m100-gen40">Distributed File Service actions to perform after the first
IPL of z/OS V2R1</h3>
<p>This topic describes Distributed File Service migration actions
that you can perform only after you have IPLed z/OS V2R1. You need a running z/OS V2R1 system to perform these actions.</p>
<p><a id="idx464"></a><a id="idx465"></a><a id="idx466"></a><a id="idx467"></a><a id="idx468"></a><a id="idx469"></a>None</p>
<h2 id="ibmhttps">IBM HTTP Server migration actions</h2>
<p>This topic describes migration actions for optional feature IBM
HTTP Server.</p>
<h3 id="ibmhttpsinstall">IBM HTTP Server actions to perform before installing z/OS V2R1</h3><a id="idx470"></a>
<p>This topic describes IBM HTTP Server migration actions that you
can perform on your current (old) system. You do not need the z/OS
V2R1 level of code to make these changes, and the changes do not require
the z/OS V2R1 level of code to run once they are made.</p>
<p><a href="e0z3m100.htm#dt2mg404">Plan for the removal of support for IBM HTTP Server</a></p>
<h4 id="dt2mg404">Plan for the removal of support for IBM HTTP Server</h4><a id="idx471"></a>
<p></p>
<p><strong>Description</strong>: z/OS
V2R1 is planned to be the last release to include the IBM HTTP Server
Powered by Domino (IHS powered by Domino ). IBM recommends you use
the IBM HTTP Server Powered by Apache, which is available in z/OS
Ported Tools as a replacement. IHS powered by Apache supports IPv6,
64-bit execution, and includes security authentication and authorization
capabilities similar to those provided in IHS powered by Domino .
Also, a refresh of IBM HTTP Server powered by Apache is planned later
in 2013. IBM plans to provide documentation help with customer migration
to IBM HTTP Server Powered by Apache.</p>
<table id="wq264" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>IBM
HTTP Server</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes,
if you use IBM HTTP Server.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<p>Remove support of IBM HTTP Server for releases of z/OS later than
z/OS V2R1.</p>
<p><strong>Reference information:</strong> 
See Statement of Direction????????</p>
<h3 id="ibmhttpserverbeipl">IBM HTTP Server actions to perform before the first IPL of
z/OS V2R1</h3>
<p>This topic describes IBM HTTP Server migration actions that you
can perform after you have installed z/OS V2R1 but before the first
time you IPL. These actions might require the z/OS V2R1 level of code to be installed but
do not require it to be active.</p>
<p>None.</p>
<h3 id="ibmhttpserverafteripl">IBM HTTP Server actions to perform after the first IPL of z/OS
V1R13</h3>
<p>This topic describes IBM HTTP Server migration actions that you
can perform only after you have IPLed z/OS V2R1. You need a running
z/OS V2R1 system to perform these actions.</p>
<p>None.</p>
<h2 id="ai1info1">Infoprint Server migration actions</h2>
<p>This topic describes migration actions for optional feature Infoprint
Server.</p>
<h3 id="e0z3m100-gen117">Infoprint Server actions to perform before installing z/OS
V2R1</h3><a id="idx472"></a>
<p>This topic describes Infoprint Server migration actions that you
can perform on your current (old) system. You do not need the z/OS V1R13 level of code to make
these changes, and the changes do not require the z/OS V1R13 level of code to run once they are
made.</p>
<p><a href="e0z3m100.htm#dt2mg412">Upgrade Java for Infoprint Server</a><a id="idx473"></a><a id="idx474"></a><a id="idx475"></a><a id="idx476"></a></p>
<h4 id="dt2mg412">Upgrade Java for Infoprint Server</h4><a id="idx477"></a>
<p>Writer: Allida Shoning (Allida.Shoning@ricoh-usa.com)
Technical: Carl Kugler (Carl.Kugler@ricoh-usa.com)</p>
<p><strong>Description</strong>: In z/OS V2R1, Infoprint Server requires Java
V7. If the JAVA_HOME environment variable specifies the location of
an earlier version of Java, you must update the JAVA_HOME environment
variable.</p>
<table id="wq265" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS Infoprint Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use the Infoprint Central or IPP
Server components of Infoprint Server and you do not have Java V7
installed or you specify the JAVA_HOME environment variable.You are
using Infoprint Central if the <strong>start-daemons={ssid}</strong> attribute
is specified in the Infoprint Server configuration file You are using
the IPP Server if the <strong>start-daemons={ippd}</strong> attribute is specified
in the Infoprint Server configuration file. The configuration file's
default location is <samp class="xph">/etc/Printsrv/aopd.conf</samp>. However,
you might have specified a different location in environment variable
AOPCONF in the <strong>aopstart</strong> EXEC.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>One of these:

<ul>
<li>IBM 31-bit SDK for z/OS, Java Technology Edition, V7 (5655-W43)</li>
<li>IBM 64-bit SDK for z/OS, Java Technology Edition, V7 (5655-W44)</li></ul>

<p>The IPP Server requires the 31-bit version.</p></td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:
</p>
<ol type="1">
<li>Install one or both of these Java products:

<ul>
<li>IBM 31-bit SDK for z/OS, Java Technology Edition, V7 (5655-W43)</li>
<li>IBM 64-bit SDK for z/OS, Java Technology Edition, V7 (5655-W44)</li></ul>If you use the IPP Server, install the 31-bit version. If you
use Infoprint Central, you can install any version.</li>
<li>If you use the IPP Server, update the directory path specified
in the JAVA_HOME environment variable in the <strong>aopstart</strong> EXEC.
The IPP Server requires the 31-bit version of Java V7.</li>
<li>If you use Infoprint Central, update the directory path specified
in the JAVA_HOME environment variable in the z/OS HTTP Server environment
variables file <samp class="xph">httpd.envvars</samp>.</li></ol>
<div>
<div class="note-noindent" id="wq267">
<span class="notetitle">Note:</span> <span class="notebody">If you installed Java V7 in the default Java directories, you
do not need to specify the JAVA_HOME environment variable.</span></div></div>
<p><strong>Reference information:</strong> For information about Java products
for z/OS, see http://www-03.ibm.com/ systems/z/os/zos/tools/java/.</p>
<h3 id="e0z3m100-gen118">Infoprint Server actions to perform before the first IPL of
z/OS V2R1</h3>
<p>This topic describes Infoprint Server migration actions that you
can perform after you have installed z/OS V2R1
but before the first time you IPL. These actions might require the z/OS V2R1 level of code to be installed
but do not require it to be active.</p>
<p>None.</p>
<h3 id="e0z3m100-gen119">Infoprint Server actions to perform after the first IPL of
z/OS V2R1</h3>
<p>This topic describes Infoprint Server migration actions that you
can perform only after you have IPLed z/OS V2R1.
You need a running z/OS V2R1
system to perform these actions.</p>
<p>None.</p>
<h2 id="ah1jes21">JES2 migration actions</h2>
<p>This topic describes migration actions for base element JES2.</p>
<h3 id="e0z3m100-gen47">JES2 actions to perform before installing z/OS V2R1</h3>
<p>This topic describes JES2 migration actions that you can perform
on your current (old) system. You do not need the z/OS V2R1 level of code to make these changes,
and the changes do not require the z/OS V2R1 level of code to run
once they are made.</p>
<p><a href="e0z3m100.htm#jes2jobmod">Change JESJOBS profiles</a><a id="idx478"></a><a id="idx479"></a><a id="idx480"></a><a id="idx481"></a></p>
<h4 id="jes2jobmod">Change JESJOBS profiles</h4><a id="idx482"></a><a id="idx483"></a><a id="idx484"></a>
<p></p>
<p>[[[[ Writer: Joshua Horton/Poughkeepsie/IBM
... Technical contact: Tom Wasik/Poughkeepsie/IBM ]]]]</p>
<p><strong>Description</strong>: In z/OS V2R1, the new Job Modify SSI 85 defines
additional resource names to the JESJOBS class. If any existing JESJOBS
entity name matches one of the new resource names, it could result
in unintended user authorization to modify job attributes. If necessary,
update your JESJOBS profiles to avoid granting unintended user authority
to modify jobs.</p>
<table id="wq268" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS JES2.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12 or z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if JESJOBS profiles could
grant unintended authority to modify jobs.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ol type="1">
<li>Search for JESJOBS profile names which match any of the new JESJOBS
resource names.</li>
<li>Ensure that your existing JESJOBS profiles grant the intended
authority, given the new use of JESJOBS by the Job Modify SSI 85.</li>
<li>If any JESJOBS profile inadvertently allows user authority to
Job Modify SSI 85 actions, update the profile or create a new profile,
if necessary.</li></ol>
<p><strong>Reference information:</strong> 
</p>
<ul>
<li><cite>z/OS JES2 Initialization and Tuning Guide</cite></li>
<li><cite>z/OS Security Server RACF Security Administrator&amp;apos;s Guide</cite>i</li>
<li><cite>z/OS Planning for Multilevel Security and
the Common Criteria</cite></li></ul><p class="indatacontent">.</p>
<h3 id="e0z3m100-gen48">JES2 actions to perform before the first IPL of z/OS V2R1</h3>
<p>This topic describes JES2 migration actions that you can perform
after you have installed z/OS V2R1 but before the first time you IPL.
These actions might require the z/OS V2R1 level of code to be installed
but do not require it to be active.</p>
<p>None.</p>
<h3 id="e0z3m100-gen49">JES2 actions to perform after the first IPL of z/OS V2R1</h3>
<p>This topic describes JES2 migration actions that you can perform
only after you have IPLed z/OS V2R1.
You need a running z/OS V2R1
system to perform these actions. <a id="idx485"></a><a id="idx486"></a><a id="idx487"></a><a id="idx488"></a><a id="idx489"></a><a id="idx490"></a></p>
<p><a href="e0z3m100.htm#jes2brodcast">Remove BRODCAST= from the OUTDEF initialization statement</a></p>
<p><a href="e0z3m100.htm#jes2jclerr">Remove JCLERR= from the JOBDEF initialization statement</a></p>
<p></p>
<h4 id="jes2brodcast">Remove BRODCAST= from the OUTDEF initialization statement</h4><a id="idx491"></a><a id="idx492"></a>
<p></p>
<p>[[[[ Writer: Joshua Horton/Poughkeepsie/IBM
... Technical contact: Tom Wasik/Poughkeepsie/IBM ]]]]</p>
<p><strong>Description</strong>: In z/OS 2.1, JES2 ignores any specifications
of the BRODCAST= parameter. TSO notify messages are sent to the user,
or are issued locally if the user is not logged on. You can no longer
use BRODCAST= to specify where TSO notify messages are sent.</p>
<table id="wq270" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS JES2.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12 or z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to avoid warning messages.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ol type="1">
<li>Check the OUTDEF statement in the JES2 initialization deck for
BRODCAST= specifications.</li>
<li>Remove BRODCAST= specifications from the OUTDEF statement.</li></ol>
<p><strong>Reference information:</strong> 
</p>
<ul>
<li><cite>z/OS JES2 Messages</cite></li>
<li><cite>z/OS JES2 Initialization and Tuning Reference</cite></li>
<li><cite>z/OS JES2 Diagnosis</cite></li></ul><em>JES2 Messages, JES2 Initialization and Tuning Reference, JES2
Commands, JES2 Diagnosis</em><p class="indatacontent">.</p>
<h4 id="jes2jclerr">Remove JCLERR= from the JOBDEF initialization statement</h4><a id="idx493"></a><a id="idx494"></a>
<p></p>
<p>[[[[ Writer: Joshua Horton/Poughkeepsie/IBM
... Technical contact: Tow Wasik/Poughkeepsie/IBM ]]]]</p>
<p><strong>Description</strong>: In z/OS V2R1, JES2 ignores any specifications
of the JCLERR= parameter. If an error on the JOB card is encountered
during the INPUT phase, the job is sent to the converter for INPUT
phase error message processing. You can no longer use JCLERR= to specify
for the job to be failed under these conditions.</p>
<table id="wq272" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS JES2.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12 or z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V2R1..</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to avoid warning messages.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ol type="1">
<li>Check the JOBDEF statement in the JES2 initialization deck for
JCLERR= specifications.</li>
<li>Remove any JCLERR= specifications from the JOBDEF statement.</li></ol>
<p><strong>Reference information:</strong> 
</p>
<ul>
<li><cite>z/OS JES2 Messages</cite></li>
<li><cite>z/OS JES2 Initialization and Tuning Reference</cite></li>
<li><cite>z/OS JES2 Diagnosis</cite></li>
<li><cite>z/OS JES2 Commands</cite></li></ul><p class="indatacontent">.</p>
<h2 id="al1jes31">JES3 migration actions</h2>
<p>This topic describes migration actions for optional feature JES3.</p>
<h3 id="e0z3m100-gen123">JES3 actions to perform before installing z/OS V2R1</h3><a id="idx495"></a>
<p>This topic describes JES3 migration actions that you can perform
on your current (old) system. You do not need the z/OS V2R1 level of code to make these changes,
and the changes do not require the z/OS V2R1
level of code to run once they are made.<a id="idx496"></a><a id="idx497"></a><a id="idx498"></a><a id="idx499"></a></p>
<p>None.</p>
<h3 id="e0z3m100-gen124">JES3 actions to perform before the first IPL of z/OS V2R1</h3>
<p>This topic describes JES3 migration actions that you can perform
after you have installed z/OS V2R1
but before the first time you IPL. These actions might require the z/OS V2R1 level of code to be installed
but do not require it to be active.<a id="idx500"></a><a id="idx501"></a><a id="idx502"></a><a id="idx503"></a><a id="idx504"></a><a id="idx505"></a></p>
<p><a href="e0z3m100.htm#jes3relform">Change JES3 release level format</a></p>
<h4 id="jes3relform">Change JES3 release level format</h4><a id="idx506"></a><a id="idx507"></a><a id="idx508"></a><a id="idx509"></a>
<p></p>
<p>[[[[ Writer: Joshua Horton/Poughkeepsie/IBM
... Technical contact: John Edwards/Rochester/IBM ]]]]</p>
<p><strong>Description</strong>: In z/OS V2R1 SSI 54, SSI 82 and SSI 83 report
the JES3 release level using the JES2 format 'z/OS 2.1'.  In previous
versions of z/OS, JES3 reported the release level using the format
'z 1.13.0'. The SSI fields which are affected by the format change
are: 
</p>
<ul>
<li>SSI 54: SSVIVERS field from macro IEFSSVI</li>
<li>SSI 82: JPXVERSN field from macro IAZJPLEX</li>
<li>SSI 83: JPSYVERN field from macro IAZJPLXI.</li></ul>
<table id="wq274" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS JES3.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12 or z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if code is dependent on the JES3 release
level returned by SSI 54, SSI 82 or SSI 83.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ol type="1">
<li>Search for fields SSVIVERS, JPXVERSN and JPSYVERN in invocations
of SSI 54, SSI 82 and SSI 83.</li>
<li>For any code that requires the z/OS 2.1 JES3 release level, change
the expected format to 'z/OS 2.1' (z/OS #.#).</li></ol>
<p><strong>Reference information:</strong> <cite>z/OS MVS Using the Subsystem Interface</cite>..</p>
<h3 id="e0z3m100-gen125">JES3 actions to perform after the first IPL of z/OS V2R1</h3>
<p>This topic describes JES3 migration actions that you can perform
only after you have IPLed z/OS V2R1. You need a running z/OS V2R1
system to perform these actions.</p>
<p>None.</p>
<h2 id="ab1bser">Library Server migration actions</h2>
<p>This topic describes migration actions for base element Library
Server.</p>
<h3 id="e0z3m100-gen57">Library Server actions to perform before installing z/OS V2R1</h3><a id="idx510"></a>
<p>This topic describes Library Server migration actions that you
can perform on your current (old) system. You do not need the z/OS
V2R1 level of code to make these changes, and the changes do not require
the z/OS V2R1 level of code to run once they are made.</p>
<p>None.</p>
<h3 id="libsb1i">Library Server actions to perform before the first IPL of z/OS
V2R1</h3>
<p>This topic describes Library Server migration actions that you
can perform after you have installed z/OS V2R1 but before the first
time you IPL. These actions might require the z/OS V2R1 level of code to be installed but
do not require it to be active.</p>
<p><a href="e0z3m100.htm#ab3conf1">Copy Library Server configuration files</a></p>
<p><a href="e0z3m100.htm#ab3note1">Copy Library Server notes files</a></p>
<h4 id="ab3conf">Copy Library Server configuration files</h4><a id="idx511"></a><a id="idx512"></a><a id="idx513"></a><a id="idx514"></a><a id="idx515"></a><a id="idx516"></a>
<p><strong>Description</strong>: The Library Server configuration
files (<samp class="xph">bookmgr.80</samp>, <samp class="xph">booksrv.80</samp>) contain information
about your environment and preferences. The information in <samp class="xph">bookmgr.80</samp> includes
the names of bookshelf lists for bookshelves in MVS&trade; data sets and the names of the HFS directories
that Library Server reads and writes during execution. The information
in <samp class="xph">booksrv.80</samp> includes the HFS directory names of book
collections, shelves, and bookcases. There are default values but
normally you would customize them. In order to bring the customized
values over to your new system, you have to copy them. (Note that
port number suffix .80, used in <samp class="xph">bookmgr.80</samp> and <samp class="xph">booksrv.80</samp>,
is an example. Your port number suffix might be different.)</p>
<table id="wq276" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Library Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you intend to preserve your Library
Server configuration.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Copy your current (customized)
configuration files, usually <samp class="xph">bookmgr.80</samp> and <samp class="xph">booksrv.80</samp>,
to your new system and add any configuration parameters that are
new since the z/OS release from which you are migrating. Otherwise
Library Server will run with default values, not the values you're
used to. A suggested (but not required) place for these configuration
files is <samp class="xph">/etc/booksrv</samp>. Library Server will also search <samp class="xph">/etc</samp> and
the original cgi-bin for them. If you place the files in any other
directory, use the EPHConfigPath environment variable to tell Library
Server where to find them.</p>
<p><strong>Reference information</strong>: For a complete description
of each parameter of the Library Server configuration files, see <cite>z/OS Program Directory</cite>.</p>
<h4 id="ab3note">Copy Library Server notes files</h4>
<p><strong>Description</strong>: Users can make comments in book
topics by creating notes that are appended to the end of each topic. <a id="idx517"></a>
If you do not copy
these notes to the new system, they will be lost.</p>
<table id="wq277" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Library Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you intend to preserve notes from release
to release.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Copy all the files from your
existing notes directory to the new one. The default directory for
saving book notes is <samp class="xph">/usr/lpp/booksrv/public/bookmgr/notes</samp>.
You can override this default by specifying a directory on the NOTEDIR
parameter of the <samp class="xph">bookmgr.80</samp> configuration file.</p>
<p><strong>Reference information</strong>: For a complete description
of each parameter of the Library Server configuration files, see <cite>z/OS Program Directory</cite>.</p>
<h3 id="e0z3m100-gen58">Library Server actions to perform after the first IPL of z/OS
V2R1</h3>
<p>This topic describes Library Server migration actions that you
can perform after you have installed z/OS V2R1 but before the first
time you IPL. These actions might require the z/OS V2R1 level of code
to be installed but do not require it to be active.</p>
<p><a href="e0z3m100.htm#dt2mg434">Reconfigure Library Server InfoCenters</a></p>
<h4 id="dt2mg434">Reconfigure Library Server InfoCenters</h4><a id="idx518"></a>
<p></p>
<p><strong>Description</strong>: Starting with z/OS V2R1, the Library Server
element requires the Location value (ICPATH=) value of InfoCenters
to be configured differently than it was in the past.  Thus, for any
existing InfoCenter configurations migrated from the previous version,
you must delete, reconfigure, re-index, and re-catalog the configurations
as described in <strong>Steps to take</strong>.  Also, if you want to configure
the z/OS MF InfoCenter (which is packaged with Library Server starting
with z/OS V2R1), you must also configure and catalog it. See the last
two steps in <strong>Steps to take</strong>.</p>
<table id="wq278" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Library
Server</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>after
the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you intend to preserve configured InfoCenters from the previous
version or configure the pre-packaged z/OS MF InfoCenter.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ol type="1">
<li>Migrate your current customized booksrv.80 as described in <strong>Description</strong>.</li>
<li>Configure and start you HTTP server as required for Library Server
as described in the <cite>z/OS Program Directory</cite>.</li>
<li>Using the Library Server Administrative Interface, delete any
existing InfoCenter configuration entries.</li>
<li>Using the Library Server Administrative Interface, reconfigure
(that is,"create new") each deleted InfoCenter, using for its <em>Location</em>field
the fully qualified "root plugin" directory name, or jar file name,
of the InfoCenter. (Note that the "root plugin" is a child of the
InfoCenter parent directory and is typically distinguishable as the
plugin that contains the "plugin_customization.ini" file for the InfoCenter.)</li>
<li>Using the Library Server Administrative Interface, re-index all
the reconfigured InfoCenters.</li>
<li>If you want to configure the z/OS MF Infocenter that is packaged
with Library Server, use the Library Server Administrative Interface
to configure it.  Specify the ID (<strong>ICIDS=</strong>), Title (<strong>INFOCENTERS= </strong>),
and Location (<strong>ICPATH=</strong>) keyword values from the installed /usr/lpp/booksrv/cgi-bin/booksrv.conf
file. (Because it is already indexed before packaging, you do not
need to re-index the z/OS MF InfoCenter.)</li>
<li>Using the Library Server Administrative Interface, rebuild the
Library Server Catalog to copy/catalog all the InfoCenter objects
(for example, TOC files, plugin card files, and any extracted PDFs)
introduced by any of the previous steps.</li></ol>
<p><strong>Reference information:</strong>  For a complete description of each
parameter of the Library Server configuration files, see the <cite>z/OS
Program Directory</cite>.</p>
<h2 id="ao1rmf">RMF migration actions</h2>
<p>This topic describes migration actions for optional feature Resource Measurement Facility&trade; (RMF).</p>
<h3 id="e0z3m100-gen59">RMF actions to perform
before installing z/OS V2R1</h3><a id="idx519"></a>
<p>This topic describes RMF migration actions that you can perform
on your current (old) system. You do not need the z/OS V2R1 level
of code to make these changes, and the changes do not require the
z/OS V2R1 level of code to run once they are made.</p>
<p>None.</p>
<h3 id="e0z3m100-gen60">RMF actions to perform
before the first IPL of z/OS V2R1</h3>
<p>This topic describes RMF migration actions that you can perform
after you have installed z/OS V2R1 but before the first time you IPL.
These actions might require the z/OS V2R1 level of code to be installed
but do not require it to be active.</p>
<p><a href="e0z3m100.htm#rmfexit1">Control the invocation of data reduction exit routines</a></p>
<p><a href="e0z3m100.htm#dt2mg442">Check your GPMSERVE and GPM4CIM options for TCP/IP address
regular expressions</a></p>
<p><a href="e0z3m100.htm#dt2mg444">Define the RACF definitions to enable the GPMSERVE Started
Task for Authorization Code zero (AC=0)</a></p>
<h4 id="rmfexit1">Control the invocation of data reduction exit routines</h4><a id="idx520"></a><a id="idx521"></a><a id="idx522"></a><a id="idx523"></a><a id="idx524"></a><a id="idx525"></a>
<p><strong>Description</strong>: Before z/OS V2R1, you could not allow unauthorized
applications to take advantage of data reduction exit routines. As
of z/OS V2R1, if you are running unauthorized applications that invoke
the RMF Monitor II Sysplex Data Gathering service (ERB2XDGS) or the
RMF Monitor III Sysplex Data Retrieval service (ERB3XDRS), you can
take certain actions to allow the applications to make use of data
reduction exit routines.</p>
<table id="wq280" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx526"></a><a id="idx527"></a><a id="idx528"></a><a id="idx529"></a><strong>Element or
feature</strong>:</td>
<td>RMF.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1. This function is rolled back to z/OS
V1R11 with APAR OA38022 for RMF Monitor II service and APAR OA37965
for RMF Monitor III service installed.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12 without the PTFs for
APARs OA38022 and OA37965.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to use the RMF Monitor II and
Monitor III sysplex data services.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: To allow your applications to make use of
data reduction exit routines specified with the ERB2XDGS or ERB3XDRS
services, take the following actions:</p>
<ul>
<li>If the application has been designed to run authorized, the application
must be adapted to run in supervisor state, system state, or be APF
authorized.</li>
<li>The exit can be approved by adding RACF resource ERBSDS.MON2EXIT.&lt;<span class="synph"><span class="kwd">exit_name</span></span>&gt;
or ERBSDS.MON3EXIT.&lt;<span class="synph"><span class="kwd">exit_name</span></span>&gt; to RACLISTed
class FACILITY and by granting read access to the profile for the
user ID invoking the Sysplex Data Server API.</li></ul>
<p><strong>Reference information</strong>: For details about the RMF sysplex
data services see <cite>z/OS RMF Programmer's Guide</cite>.</p>
<h4 id="dt2mg442">Check your GPMSERVE and GPM4CIM options for TCP/IP address
regular expressions</h4><a id="idx530"></a>
<p>[[[Juergen
Kuhn/Germany/IBM@IBMDE]]]</p>
<p><strong>Description</strong>: Starting with z/OS V2R1, the RMF GPMSERVE Started
Task runs as a module linked with Authorization Code zero  (AC=0).
The following two actions are required with regard to RACF. 
</p>
<ol type="1">
<li>Define READ access to the BPX.SERVER FACILITY class for the GPMSERVE
userid.</li>
<li>Ensure that all programs loaded by GPMSERVE are defined to PROGRAM
CONTROL.</li></ol>
<table id="wq282" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>RMF</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes,
if you use GPMSERVE or GPM4CIM with IPv6 address regular expressions.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If you use GPMSERVE or GPM4CIM in an IPv6
or dual mode IPv6/IPv4 network environment, check one or more of your
options parmlib members for options containing regular expressions
representing IP addresses (for example, the options HTTP_ALLOW or
HTTP_NOAUTH). Make sure that the regular expressions adhere strictly
to the format of the IP addresses in your network. Examples include
the following:
</p>
<table id="wq283" width="100%" summary="" border="1" frame="border" rules="all">
<caption><a href="e0z3m100.htm#FT_Table_11">Table 11. Examples of IP matches</a></caption>
<thead valign="bottom">
<tr valign="bottom">
<th id="wq284" width="14%" align="left">IP address expression</th>
<th id="wq285" width="31%" align="left">Match</th>
<th id="wq286" width="53%" align="left">Examples of full IP address match</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq284">'6.*'</td>
<td headers="wq285">Matches any IP address starting with '6.'</td>
<td headers="wq286">6.19.107.32' or '6.34.88.103'</td>
</tr>
<tr>
<td headers="wq284">'::ffff:6.*'</td>
<td headers="wq285">Matches any (mapped) IP address starting with
'::ffff:6.'</td>
<td headers="wq286">'::ffff:6.19.107.32' or '::ffff:6.9.50.7'</td>
</tr>
<tr>
<td headers="wq284">'*6.*'</td>
<td headers="wq285">Matches any IP address containing a substring
'6.'</td>
<td headers="wq286">'::ffff:6.9.50.7' or '6.19.107.32'</td>
</tr>
</tbody>
</table>
<p><strong>Reference information</strong>For
further information see <span id="xfmtmark-gen1__erbb200t">z/OS RMF User's Guide</span>:</p>
<h4 id="dt2mg444">Define the RACF definitions to enable the GPMSERVE Started
Task for Authorization Code zero (AC=0)</h4><a id="idx531"></a>
<p></p>
<p>
<h5 id="wq287">Description:</h5><a id="idx532"></a></p>
<p>
<p>Starting with z/OS V2R1, the RMF GPMSERVE Started Task runs
as a module linked with Authorization Code zero  (AC=0).</p>
<p>The following
two actions are required with regard to RACF.
</p>
<ol type="1">
<li>Define READ access to the BPX.SERVER FACILITY class for the GPMSERVE
userid</li>
<li>Ensure that all programs loaded by GPMSERVE are defined to PROGRAM
CONTROL</li></ol></p>
<table id="wq290" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>RMF</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p>
<h5 id="wq291">Steps to take:</h5></p>
<ol type="1">
<li>Define READ Access to the BPX.SERVER Facility for the GPMSERVE
userid: 
<pre class="xmp"><code>PERMIT BPX.DAEMON CLASS(FACILITY) ID(GPMSERVE) ACCESS(READ)</code></pre></li>
<li>Ensure that all programs loaded by GPMSERVE are defined to PROGRAM
CONTROL:    
<pre class="xmp"><code>RDEFINE PROGRAM GPM* ADDMEM(&rsquo;SYS1.SERBLINK&rsquo;//NOPADCHK) UACC(READ)
RDEFINE PROGRAM ERB* ADDMEM(&rsquo;SYS1.SERBLINK&rsquo;//NOPADCHK) UACC(READ)
RDEFINE PROGRAM CEEBINIT ADDMEM(&rsquo;CEE.SCEERUN&rsquo;//NOPADCHK) UACC(READ)
RDEFINE PROGRAM IEEMB878 ADDMEM(&rsquo;SYS1.LINKLIB&rsquo;//NOPADCHK) UACC(READ)
RDEFINE PROGRAM CELHV003 ADDMEM(&rsquo;SYS1.SCEERUN2&rsquo;//NOPADCHK) UACC(READ)
RDEFINE PROGRAM C128 ADDMEM(&rsquo;SYS1.SCEERUN2&rsquo;//NOPADCHK) UACC(READ)
RDEFINE PROGRAM CELHDCPP ADDMEM(&rsquo;SYS1.SCEERUN2&rsquo;//NOPADCHK) UACC(READ)
SETROPTS WHEN(PROGRAM) REFRESHs</code></pre> This action is only needed
when GPMSERVE is not already defined to PROGRAM CONTROL. In previous
RMF Releases this was recommended  but not required since the GPMSERVE
module was linked with Authorization Code one (AC=1).</li></ol>
<p>
<h5 id="wq293">Reference information:</h5>
<p>For
further information see <em>z/OS RMF User's Guide.</em></p></p>
<h3 id="e0z3m100-gen61">RMF actions to perform
after the first IPL of z/OS V2R1</h3>
<p>This topic describes RMF migration
actions that you can perform only after you have IPLed z/OS V2R1. You need a running z/OS V2R1 system to perform these actions.</p>
<p><a href="e0z3m100.htm#rmflater1">Use an RMF Monitor III
reporter version equal to or later than your RMF Monitor III gatherer version</a></p>
<p><a href="e0z3m100.htm#rmfzfs1">Monitor the zFS file system activity</a></p>
<p><a href="e0z3m100.htm#psdrept">Determine need of SMF data collection for Postprocessor
PCIE Activity report based on SMF 74.9 record.</a></p>
<h4 id="rmflater">Use an RMF Monitor III
reporter version equal to or later than your RMF Monitor III gatherer version</h4><a id="idx533"></a><a id="idx534"></a><a id="idx535"></a><a id="idx536"></a><a id="idx537"></a><a id="idx538"></a>
<p>[[[[ Contributing writer: Stephan Hartig/Germany/IBM@IBMDE
]]]] [[[[ Technical contact: Peter Muench]]]]</p>
<p><strong>Description</strong>: To avoid problems when
reporting Monitor III data, use an RMF reporter
version that is equal to or later than the latest RMF gatherer version used to collect the data to
be reported. For example, it is safe to use an RMF reporter version
from z/OS V2R1 for data collected with an RMF gatherer from z/OS V1R12,
but not vice versa. <a id="idx539"></a></p>
<p>Mixed (and therefore problematic) levels of collected data can
occur in the following scenarios: 

</p>
<ul>
<li><em>Single system</em>: You install and test a
new release, then fall back to an earlier one; your data sets might
contain data collected with different versions of the RMF gatherer.</li>
<li><em>Sysplex</em>: You migrate to a new release
on one system in a sysplex but try to use an earlier reporter version
from another system to report on the migrated system's data.</li></ul>
<table id="wq294" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>RMF.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you had planned to use an earlier-level RMF reporter on data that was collected
with a later-level RMF gatherer.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>See &quot;Steps to take&quot; below.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Always use an RMF Monitor III reporter version that is equal to
or later than the gatherer version used to collect the data from which
you want to produce a report.</p>
<div>
<div class="note-noindent" id="wq295">
<span class="notetitle">Note:</span> <span class="notebody">Monitor III notifies users by issuing information
message ERB948I when a reporter session is started on a system in
a sysplex that is not running with the highest RMF level available in the sysplex. The message helps
users to avoid reporting problems.</span></div></div>
<p><strong>Reference information</strong>: For more information
about Monitor III commands, see <cite>z/OS RMF User's Guide</cite>.</p>
<h4 id="rmfzfs1">Monitor the zFS file system activity</h4>
<p><strong>Description</strong>: Before z/OS V2R1, the RMF Monitor III data
gatherer ERBRMF04 parmlib options ZFS and NOZFS controlled the data
collection for measuring zFS file system activity, the default was
to activate the data collection. As of V2R1, RMF no longer automatically
gathers any data about zFS file system activity.</p>
<table id="wq296" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx540"></a><a id="idx541"></a><a id="idx542"></a><strong>Element or feature</strong>:</td>
<td>RMF.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to collect data about zFS file
system activity.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Determine if you want to monitor zFS file
system activity. When starting a Monitor III session in this case,
you can permanently specify the ZFS option in the parmlib member for
your Monitor III data gatherer sessions. Or you can use the following
RMF MODIFY command during a running session:  </p>
<pre class="xmp"><code>MODIFY RMF,MODIFY III,ZFS</code></pre>
<div>
<div class="note-noindent" id="wq297">
<span class="notetitle">Note:</span> <span class="notebody">When the default of NOZFS is in effect, the dataspace ERBZFSDS
is no longer created. Check for the dump commands that specify the
ERBZFSDS as DSPNAME= option. RMF Monitor III uses additional data
spaces, so you should not remove any DSPNAME parameter that specifies
a wildcard data space name. Failure to remove the DSPNAME for the
non-existent data spaces continues with a dump taken as normal and
with message ASA104I SYNTAX ERROR. See the DOC APAR OA39627 for this
message. Because FFST dumps do not include data spaces, they are not
affected.</span></div></div>
<p><strong>Reference information</strong>: For details about zFS file system
data gathering see <cite>z/OS RMF User's Guide</cite>.</p>
<h4 id="psdrept">Determine need of SMF data collection for Postprocessor
PCIE Activity report based on SMF 74.9 record.</h4>
<p>[[[[ Contributing writer: Stephan Hartig/Germany/IBM@IBMDE
]]]] [[[[ Technical contact: Regine Reichert/Germany/IBM@IBMDE ]]]]</p>
<p><strong>Description</strong>: Starting with z/OS V2R1, RMF provides a new
Postprocessor PCIE Activity report based on SMF 74.9 record. If you
do not need this report, <span>you should turn off data collection
for SMF record 74 subtype 9.</span><a id="idx543"></a><a id="idx544"></a></p>
<table id="wq298" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>RMF.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if you do not want to collect
SMF data for the Postprocessor PCIE Activity report.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Determine if you want to use the new Postprocessor
PCIE Activity report. SMF data required for this report is gathered
by default. If you do not want to use this report, you should suppress
the SMF data collection for the new record type 74 subtype 9. You
achieve this by specifying NOTYPE for this SMF record type in the
SMF parmlib member SMFPRM<span class="synph"><span class="var">xx</span></span>.</p>
<p>Another method to suppress the data gathering of record
74.9 for the Postprocessor PCIE Activity report is to use the SUBSYS
parameter in the SMFPRM<span class="synph"><span class="var">xx</span></span> parmlib member
for the STC subsystem (started tasks, where RMF is one of them). To
exclude data gathering for SMF record 74.9, specify <span class="synph"><span class="kwd">SUBSYS(STC,NOTYPE(74(9)),
... )</span></span>.</p>
<p>The SUBSYS specification overrides the SYS specification.
So for example, if you have defined <span class="synph"><span class="kwd">SYS(TYPE(...,74,...))</span></span> in
your SMFPRM<span class="synph"><span class="var">xx</span></span> parmlib member, you can use <span class="synph"><span class="kwd">SUBSYS(STC,
NOTYPE(74(9)))</span></span> to make exceptions to your SYS specification
and just exclude gathering of SMF record 72.5 for started tasks like
RMF.</p>
<p><strong>Reference information</strong>: For details about specifying SMF
data collection, see <cite>z/OS MVS Initialization and Tuning Reference</cite>.</p>
<h2 id="ap1sdsf">SDSF migration actions</h2>
<p>This topic describes migration actions for optional feature SDSF.</p>
<h3 id="e0z3m100-gen62">SDSF actions to perform before installing z/OS V2R1</h3><a id="idx545"></a>
<p>This topic describes SDSF migration actions that you can perform
on your current (old) system. You do not need the z/OS V2R1 level
of code to make these changes, and the changes do not require the
z/OS V2R1 level of code to run once they are made.</p>
<p>None.</p>
<h3 id="e0z3m100-gen63">SDSF actions to perform before the first IPL of z/OS V2R1</h3>
<p>This topic describes SDSF migration actions that you can perform
after you have installed z/OS V2R1 but before the first time you IPL.
These actions might require the z/OS V2R1
level of code to be installed but do not require it to be active.</p>
<p><a href="e0z3m100.htm#ax3exit1">Review and reassemble user exit routines</a></p>
<p><a href="e0z3m100.htm#ax3assm1">Use dynamic statements for ISFPARMS to avoid reassembly</a></p>
<h4 id="ax3exit">Review and reassemble user exit routines</h4><a id="idx546"></a><a id="idx547"></a><a id="idx548"></a><a id="idx549"></a><a id="idx550"></a><a id="idx551"></a>
<p><strong>Description</strong>: If you have written
user exit routines, review them to ensure they are still appropriate
for the current environment, and make changes as necessary. <a id="idx552"></a><a id="idx553"></a>
All
user exit routines must be reassembled with the z/OS V2R1 level of
the SDSF macro library.</p>
<table id="wq299" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>SDSF.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if user exit routines are in use.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Review user exit
routines to ensure they are appropriate for z/OS V2R1. Make changes
as necessary. Regardless of whether you have made changes, reassemble
the user exit routines with the z/OS V2R1
level of the SDSF macro library.</p>
<p>Tip: A PROPLIST statement, along with PROPERTY statements,
both in the ISFPRM<span class="synph"><span class="var">xx</span></span> parmlib member, defines customized values
for certain SDSF properties. It provides an alternative to writing
user exit routines to customize those properties. A user exit routine
that customizes the same property as a PROPERTY statement overrides
the value on the PROPERTY statement.</p>
<p><strong>Reference information</strong>: See <cite>z/OS SDSF Operation and Customization</cite>.</p>
<h4 id="ax3assm">Use dynamic statements for ISFPARMS to avoid reassembly</h4>
<p><strong>Description</strong>: ISFPARMS in SDSF is used for
specifying global options, the format of panels, and security for
SDSF functions.  SDSF provides two alternatives for ISFPARMS:

</p>
<ul>
<li>Assembler macros that you define, assemble, and then link into
the SDSF load library. This is the original format for defining ISFPARMS
and it continues to be supported for compatibility.</li>
<li>Dynamic statements, which are in parmlib member ISFPRM<span class="synph"><span class="var">xx</span></span>.
Dynamic statements are the recommended format. They are easier to
code and are more dynamic than the assembler macros; they can be updated
without reassembling or link-editing. The statements are processed
by an SDSF server, which is controlled by MVS operator
commands.</li></ul>
<table id="wq300" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx554"></a><strong>Element or feature</strong>:</td>
<td>SDSF.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to avoid the migration action
of reassembling your customized ISFPARMS for each z/OS release.  (If you do not use dynamic statements
for ISFPARMS, reassembly of your customized ISFPARMS is required on
each release.)</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>Use check SDSF_ISFPARMS_IN_USE to verify that
SDSF dynamic statements in ISFPRM<span class="synph"><span class="var">xx</span></span> are being used rather
than the assembler macros. If the check determines that the assembler
macro ISFPARMS is in use instead, and that it has been modified, the
check generates an exception. If the assembler macro ISFPARMS is in
use but it has not been modified, so that all defaults are in effect,
the check does not generate an exception.


<p>SDSF registers this check
with the IBM Health Checker
for z/OS infrastructure when the SDSF server address space is initialized.
However, one of the items this check verifies is that the SDSF server
itself is in use, so you have to manually add this check (particularly
if you do not use the SDSF server) so that the IBM Health Checker for z/OS infrastructure will
invoke the check. To add the check, put the following statement in
your PROG<span class="synph"><span class="var">xx</span></span> parmlib member: <samp class="xph">EXIT ADD EXITNAME(HZSADDCHECK)
MODNAME(ISFHCADC)</samp>.</p>


<p>SDSF health checks are distributed
in ISF.SISFLOAD for installations running SDSF in the LNKLST. The
checks are also distributed in ISF.SISFLINK for installations that
do not run SDSF in the LNKLST. For those installations, ISF.SISFLINK
must be added to the LNKLST.</p>


<p></p>
<div>
<div class="note-noindent" id="wq301">
<span class="notetitle">Note:</span> <span class="notebody"> To avoid a possible
ABEND 290 with reason code 02014007 issued by HZSADDCK: 


<ul>
<li>Make sure that you specify the proper check routine name. The
check routine module must be in an APF-authorized library. The system
must be able to locate the check routine within the joblib, the steplib
of the IBM Health Checker for z/OS address space, the LPA, or the
LNKLST.</li>
<li>Make sure that you specify the proper message table name. The
message table module must be in an APF-authorized library. The system
must be able to locate the message table within the joblib, the steplib
of the IBM Health Checker for z/OS address space, the LPA, or the
LNKLST.</li></ul></span></div></div></td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If you are already using dynamic
statements for ISFPARMS<span class="synph"><span class="var">xx</span></span>, there is no migration action to
perform.</p>
<p>If you are using assembler macros for ISFPARMS, do one of the following:

</p>
<ul>
<li>Convert your existing ISFPARMS to dynamic statements by using
a conversion utility that you invoke with the ISFACP command.</li>
<li>Reassemble your customized ISFPARMS for use with z/OS V2R1.  Reassembly must be done whenever you
change your z/OS release. Before reassembling ISFPARMS, you might
want to update it for new function. The assembler ISFPARMS cannot
be shared with any other release of SDSF. Only use ISFPARMS for the
release on which it is assembled. 

<div>
<div class="note-noindent" id="wq302">
<span class="notetitle">Note:</span> <span class="notebody">Sample
job ISFPARME has been removed from the samples supplied with SDSF.
This job contained SMP/E control statements to receive the sample
assembler macro ISFPARMS as a user modification (usermod). If you
have an SMP/E usermod that specifies modifications to assembler macro
ISFPARMS, change the usermod to indicate that module ISFPARMS is now
owned by the SDSF JES2 feature FMID (JJE778S) and not the base SDSF
FMID (HQX7780). The correct SMP/E syntax is ++VER(Z038) FMID(JJE778S),
not ++VER(Z038) FMID(HQX7780).</span></div></div></li></ul>
<p><strong>Reference information</strong>: 

</p>
<ul>
<li>For details about invoking the conversion utility with the ISFACP
command, see <cite>z/OS SDSF Operation and Customization</cite>.</li>
<li>For information about ISFPARMS and the ISFPRM<span class="synph"><span class="var">xx</span></span> parmlib
member, see "ISFPARMS format alternatives" in  <cite>z/OS SDSF Operation and Customization</cite>.</li></ul>
<h3 id="e0z3m100-gen64">SDSF actions to perform after the first IPL of z/OS V2R1</h3>
<p>This topic describes SDSF migration actions that you can perform
only after you have IPLed z/OS V2R1. You need a running z/OS V2R1
system to perform these actions.</p>
<p><a href="e0z3m100.htm#dt2mg762">Control how SDSF handles MCS extended (EMCS) consoles</a></p>
<h4 id="sdsf_v21">Control how SDSF handles extended consoles</h4><a id="idx555"></a><a id="idx556"></a><a id="idx557"></a><a id="idx558"></a><a id="idx559"></a><a id="idx560"></a>
<p>[[[[ Contributing writer: Bill Keller]]]]
[[[[ Technical contact: Ken Jonas]]]]</p>
<p><strong>Description</strong>: As of z/OS V2R1, the behavior for obtaining
an extended console (used for issuing system commands) has changed.
Before z/OS V2R1, when SDSF attempted to obtain an extended console
and the default extended console name was already in use, SDSF shared
that console. For example, if you used ISPF split screen and accessed
SDSF in multiple logical screens, SDSF shared the console activated
in the first logical screen with subsequent logical screens. As a
result, the user log in the first logical screen contained system
messages for all of the logical screens.<a id="idx561"></a><a id="idx562"></a></p>
<p>With V2R1, when SDSF attempts to activate an extended console and
the default console name is in use, SDSF activates a new console with
a different name. The new name is derived by appending a single-character
suffix to the default name. SDSF tries up to 32 different characters
to create a unique console name.</p>
<p> If you want SDSF to share the extended console, rather than obtaining
a new console with a name derived by modifying the default console
name, you can disable console name modification. You can also define
which characters should be used for the suffix that modifies the default
console name.</p>
<table id="wq303" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>SDSF.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want SDSF to share the extended
console, as in previous releases.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: To disable console name modification, so
that, as in previous releases, SDSF shares the extended console when
the default name is already in use, you can use: 
</p>
<ul>
<li>The SET CONMOD (ON|OFF) command</li>
<li>The custom property Console.EMCS.NoConMod in ISFPARMS</li>
<li>In a REXX exec, the ISFCONMOD special variable</li>
<li>In a Java program, ISFRequestSettings.</li></ul>
<p>To specify which characters can be used as a suffix to modify the
default extended console name, use custom property Console.EMCS.ConModChars
in ISFPARMS. By default, the characters are $#@12345.</p>
<p><strong>Reference information</strong>: For details about setting custom
properties in ISFPARMS, see the discussion of the PROPLIST nad PROPERTY
statements in <cite>z/OS SDSF Operation and Customization</cite>.</p>
<h2 id="aq1secs">Security Server migration actions</h2>
<p>This topic describes migration actions for optional feature Security
Server.</p>
<h3 id="e0z3m100-gen65">Security Server actions to perform before installing z/OS V2R1</h3><a id="idx563"></a>
<p>This topic describes Security Server migration actions that you
can perform on your current (old) system. You do not need the z/OS
V2R1 level of code to make these changes, and the changes do not require
the z/OS V2R1 level of code to run once they are made.<a id="idx564"></a><a id="idx565"></a><a id="idx566"></a><a id="idx567"></a><a id="idx568"></a></p>
<p><a href="e0z3m100.htm#omvs1"> Discontinue using the default OMVS segment support</a></p>
<h4 id="omvs1"> Discontinue using the default OMVS segment support</h4>
<p>[[[[ Marna Walle]]]]</p>
<p><strong>Description</strong>: IBM has strongly discouraged customers
from using default OMVS segments and instead recommends that all z/OS
UNIX users or groups have OMVS segments defined for user and group
profiles with unique UIDs and GIDs.  Use of RACF support for automatically
generating unique UIDs and GIDs on demand for users and groups that
do not have OMVS segments defined is the recommended alternative.
Support for automatic unique UID and GID generation has been available
since z/OS V1R11.</p>
<p>As of z/OS V2R1, the ability to use default OMVS segments
has been removed.</p>
<table id="wq304" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Security Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1. See RFA IBM United States Software
Announcement 211-007, dated February 15, 2011.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are using the default OMVS segment
support.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>You need AIM Stage 3 to use the BPX.UNIQUE.USER
profile. You can run the IRRIRA00 utility to determine the current
AIM Stage in your RACF database.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>Use check ZOSMIGV2R1_DEFAULT_UNIX_ID introduced
in APAR OA37164. This check determines if you are relying on assigning
default z/OS UNIX identities for users without OMVS segments.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Follow the steps in <cite>z/OS UNIX System Services Planning</cite> to
set up the BPX.UNIQUE.USER profile. If BPX.DEFAULT.USER has not been
deleted, BPX.UNIQUE.USER takes precedence when default OMVS segments
are used.</p>
<p>To remove the BPX.DEFAULT.USER profile, use the following RACF commands: </p>
<pre class="xmp"><code>RDELETE FACILITY BPX.DEFAULT.USER 
SETROPTS RACLIST(FACILITY) REFRESH</code></pre>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li><cite>z/OS UNIX System Services Planning</cite></li>
<li><cite>z/OS Security Server RACF Security Administrator&amp;apos;s Guide</cite></li></ul>
<h3 id="e0z3m100-gen66">Security Server actions to perform before the first IPL of
z/OS V2R1</h3>
<p>This topic describes Security Server migration actions that you
can perform after you have installed z/OS V2R1 but before the first
time you IPL. These actions might require the z/OS V2R1 level of code to be installed but
do not require it to be active.</p>
<p><a href="e0z3m100.htm#aq3cdcn1">Check for duplicate class names</a></p>
<p><a href="e0z3m100.htm#dt2mg467">Change CHOWN.UNRESTRICTED profile in the RACF UNIXPRIV class
from an existence check to an authorization check.</a></p>
<p><a href="e0z3m100.htm#e0z3m100-gen140">Normalize user names specified as X.500 distinguished names
in distributed identity filters</a></p>
<h4 id="aq3cdcn1">Check for duplicate class names</h4><a id="idx569"></a><a id="idx570"></a><a id="idx571"></a><a id="idx572"></a><a id="idx573"></a><a id="idx574"></a><a id="idx575"></a>
<p><strong>Description</strong>: When new classes are
shipped with RACF, you should
verify that any installation-defined class names that have been added
to the class descriptor table (CDT) do not conflict with the new classes. <a id="idx576"></a><a id="idx577"></a><a id="idx578"></a><a id="idx579"></a><a id="idx580"></a>
For a list of new classes shipped with RACF, see <cite>z/OS Summary of Message and Interface Changes</cite>.</p>
<table id="wq305" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Security Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have user-defined classes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Verify that any installation-defined
class names that have been added to the class descriptor table (CDT)
do not conflict with the new classes.</p>
<ul>
<li>If you have duplicate class names, RACF issues the following message
and enters failsoft mode: 

<pre class="xmp"><code>ICH564A RACF DETECTED AN ERROR IN THE INSTALLATION CLASS DESCRIPTOR TABLE,
ENTRY <span class="synph"><span class="var">class_name</span></span>, ERROR CODE 7</code></pre></li>
<li>If a conflict in class names occurs, resolve it as follows:


<ol type="1">
<li>Delete the profiles in the installation-defined class with the
conflicting name.</li>
<li>Delete the CDT entry for the class.</li>
<li>Add a CDT entry with a different name.</li>
<li>Redefine the profiles.</li></ol></li></ul>
<p><strong>Reference information</strong>: See <cite>z/OS Security Server RACF System Programmer&amp;apos;s Guide</cite>.</p>
<h4 id="dt2mg467">Change CHOWN.UNRESTRICTED profile in the RACF UNIXPRIV class
from an existence check to an authorization check.</h4><a id="idx581"></a>
<p></p>
<p><strong>Description</strong>: Starting in z/OS V2R1, ICSF will remove the
support for CCF and PCICC devices, which are only present on the z900
machine.</p>
<table id="wq307" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Security
Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
the first IPL.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No,
but recommended for system security.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>IRRXUTIL
to detect if the profile is present, and report on its UACC and access
list.  But a simple RLIST command will accomplish the same goal.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<p><strong>Reference information:</strong></p>
<h4 id="e0z3m100-gen140">Normalize user names specified as X.500 distinguished names
in distributed identity filters</h4><a id="idx582"></a><a id="idx583"></a><a id="idx584"></a>
<p>Go to <a href="e0z3m100.htm#distname">Normalize user names specified as X.500 distinguished names
in distributed identity filters</a>.</p>
<h3 id="e0z3m100-gen68">Security Server actions to perform after the first IPL of z/OS
V2R1</h3>
<p>This topic describes Security Server migration actions that you
can perform only after you have IPLed z/OS V2R1. You need a running
z/OS V2R1 system to perform these actions.</p>
<p><a href="e0z3m100.htm#aq3dbte1">Update database templates</a></p>
<p><a href="e0z3m100.htm#e0z3m100-gen142">Normalize user names specified as X.500 distinguished names
in distributed identity filters</a></p>
<h4 id="aq3dbte1">Update database templates</h4><a id="idx585"></a><a id="idx586"></a><a id="idx587"></a><a id="idx588"></a><a id="idx589"></a><a id="idx590"></a><a id="idx591"></a>
<p><strong>Description</strong>: To ensure that the RACF utilities function properly,
use the IRRMIN00 utility to update the test and production RACF databases with the database
templates for the current release level.<a id="idx592"></a><a id="idx593"></a><a id="idx594"></a></p>
<table id="wq308" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Security Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: To install the database template
updates, run the IRRMIN00 utility with PARM=UPDATE.</p>
<div>
<div class="note-noindent" id="wq309">
<span class="notetitle">Note:</span> <span class="notebody">If IRRMIN00 produces a return code of 4 and message <samp class="xph">IRR8025
PARM=UPDATE specified, but template update not required</samp>, you
do not necessarily have a problem. Check that your JCL points to the
new level of IRRMIN00. If it does, ignore the return code and warning
message. A PTF might have already brought your templates up to the
current level for the new release. If your JCL accidentally points
to an old copy of IRRMIN00, correct the JCL and run IRRMIN00 again.</span></div></div>
<p><strong>Reference information</strong>: 

</p>
<ul>
<li><cite>z/OS Program Directory</cite></li>
<li><cite>ServerPac: Installing
Your Order</cite></li>
<li><cite>z/OS Security Server RACF System Programmer&amp;apos;s Guide</cite></li></ul>
<h4 id="e0z3m100-gen142">Normalize user names specified as X.500 distinguished names
in distributed identity filters</h4><a id="idx595"></a><a id="idx596"></a><a id="idx597"></a>
<p>Go to <a href="e0z3m100.htm#distname">Normalize user names specified as X.500 distinguished names
in distributed identity filters</a>.</p>
<h2 id="ac1ccpp">XL C/C++ migration actions</h2>
<p>This topic describes migration actions for optional feature
XL C/C++.</p>
<h3 id="e0z3m100-gen72">XL C/C++ actions to perform before installing z/OS V2R1</h3><a id="idx598"></a><a id="idx599"></a>
<p>This topic describes XL C/C++ migration actions that you can perform
on your current (old) system. You do not need the z/OS V2R1 level of code to make these changes,
and the changes do not require the z/OS V2R1 level of code to run
once they are made.</p>
<p><a href="e0z3m100.htm#revappl1">Review the XL C/C++ Migration Guide for the Application Programmer</a></p>
<h4 id="revappl1">Review the XL C/C++ Migration Guide for the Application Programmer</h4><a id="idx600"></a><a id="idx601"></a><a id="idx602"></a><a id="idx603"></a>
<p>[[[[ Contributing writer: James E Becker/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Requestor: Marna Walle/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: The publication 
<cite>z/OS XL C/C++ Compiler and Runtime Migration Guide for the Application Programmer</cite> is written for application programmers,
whereas this publication (<em>z/OS Migration</em>) is written for system programmers.
However, in some customer locations, job scope could overlap such
that system programmers might find information in the XL C/C++ publication
that is relevant to their responsibilities. For example, migration
information related to the c89 utility in the XL C/C++ publication
could be of interest. Therefore, you ought to review the XL C/C++
publication if you use XL C/C++.</p>
<table id="wq310" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>C/C++ without Debug Tool.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if you use XL C/C++.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Look through 
<cite>z/OS XL C/C++ Compiler and Runtime Migration Guide for the Application Programmer</cite> for migration information that is relevant
to your installation.</p>
<p><strong>Reference information</strong>: <cite>z/OS XL C/C++ Compiler and Runtime Migration Guide for the Application Programmer</cite></p>
<h3 id="e0z3m100-gen73">XL C/C++ actions to perform before the first IPL of z/OS V2R1</h3>
<p>This topic describes XL C/C++ migration actions that you can perform
only before you have IPLed z/OS V2R1. You need a running z/OS V2R1
system to perform these actions.<a id="idx604"></a><a id="idx605"></a><a id="idx606"></a><a id="idx607"></a><a id="idx608"></a><a id="idx609"></a></p>
<p>None.</p>
<h3 id="e0z3m100-gen74">XL C/C++ actions to perform after the first IPL of z/OS V2R1</h3>
<p>This topic describes XL C/C++ migration actions that you can perform
only after you have IPLed z/OS V2R1. You need a running z/OS V2R1
system to perform these actions.<a id="idx610"></a><a id="idx611"></a><a id="idx612"></a><a id="idx613"></a><a id="idx614"></a><a id="idx615"></a></p>
<p>None.</p>
<h2 id="font">z/OS Base Font Collection migration actions</h2>
<p>This topic describes migration actions for the optional element
z/OS Font Collection. z/OS Font Collection is a new z/OS optional
feature for z/OS V2R1.</p>
<h3 id="e0z3m100-gen75">z/OS Base Font Collection actions to perform before installing
z/OS V2R1</h3><a id="idx616"></a>
<p>This topic describes z/OS Font Collection actions that you can
perform on your current (old) system. You do not need the z/OS V2R1 level of code to make
these changes, and the changes do not require the z/OS V2R1 level of code to run once they are made.</p>
<p>None.</p>
<h3 id="e0z3m100-gen76">z/OS Base Font Collection actions to perform before the first
IPL of z/OS V2R1</h3><a id="idx617"></a>
<p>This topic describes z/OS Font Collection migration actions that
you can perform after you have installed z/OS V2R1 but before the first time you IPL.
These actions might require the z/OS V2R1
level of code to be installed but do not require it to be active.</p>
<p><a href="e0z3m100.htm#fontcol1">Stop using old fonts and start using the fonts from the z/OS
Font Collection</a></p>
<h4 id="fontcol1">Stop using old fonts and start using the fonts from the z/OS
Font Collection</h4>
<p>[[[[ Contributing writer: &lt;Example,
Jim Guilianelli/Poughkeepsie/IBM@IBMUS &gt; ]]]] [[[[ Technical contact: &lt;Example:
Marna Walle/Poughkeepsie/IBM@IBMUS &gt; ]]]]</p>
<p><strong>Description</strong>: z/OS V2R1 contains a new base element:  z/OS
Font Collection.  The z/OS Font Collection provides fonts that were
previously marketed and serviced for z/OS.  The z/OS Font Collection
will include both single-byte and double-byte fonts.</p>
<p>The z/OS Font Collection includes:  
</p>
<ul>
<li>AFP outline fonts.</li>
<li>AFP raster fonts, including a complete set of IBM expanded core
fonts and a set of Math, PI, and Sonoran 240-pel raster fonts.</li>
<li>TrueType and OpenType fonts. These fonts have not been made available
as a separate program product for z/OS before, and are an enhancement
as of z/OS V2R1.</li></ul>
<p>The following table summarizes the existing font programs
and whether the z/OS Font Collection base element can replace them
along with the replacement name in the collection:
</p>
<table id="fontcol1__fontsincludedinthezosfontcollection" width="100%" summary="" border="1" frame="border" rules="all">
<caption><a href="e0z3m100.htm#FT_Table_12">Table 12. Existing font products and replacements in the z/OS Font Collection base element</a></caption>
<thead valign="bottom">
<tr valign="bottom">
<th id="wq311" width="15%" align="left">Program number</th>
<th id="wq312" width="25%" align="left">Product name</th>
<th id="wq313" width="7%" align="left">V.R.M.</th>
<th id="wq314" width="16%" align="left">ServerPac in Japan</th>
<th id="wq315" width="12%" align="left">PDO in Japan</th>
<th id="wq316" width="22%" align="left">Included in the V2R1 z/OS Font Collection as
base feature</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq311">5655-M32</td>
<td headers="wq312">PSF V4 for z/OS</td>
<td headers="wq313">4.4.0</td>
<td headers="wq314">Orderable</td>
<td headers="wq315">Orderable</td>
<td headers="wq316">N/A</td>
</tr>
<tr>
<td headers="wq311">5655-M32</td>
<td headers="wq312">MVS Download</td>
<td headers="wq313">4.4.0</td>
<td headers="wq314">Orderable</td>
<td headers="wq315">Orderable</td>
<td headers="wq316">N/A</td>
</tr>
<tr>
<td headers="wq311">5655-M32</td>
<td headers="wq312">Enhanced ACIF</td>
<td headers="wq313">4.4.0</td>
<td headers="wq314">Orderable</td>
<td headers="wq315">Orderable</td>
<td headers="wq316">N/A</td>
</tr>
<tr>
<td headers="wq311">5655-M32</td>
<td headers="wq312">Compatibility Fonts</td>
<td headers="wq313">4.4.0</td>
<td headers="wq314">Orderable</td>
<td headers="wq315">Orderable</td>
<td headers="wq316">N/A</td>
</tr>
<tr>
<td headers="wq311">5655-M32</td>
<td headers="wq312">AFP Upload</td>
<td headers="wq313">4.4.0</td>
<td headers="wq314">Orderable</td>
<td headers="wq315">Orderable</td>
<td headers="wq316">N/A</td>
</tr>
<tr>
<td headers="wq311">5655-M32</td>
<td headers="wq312">AFP Download Plus</td>
<td headers="wq313">4.4.0</td>
<td headers="wq314">Orderable</td>
<td headers="wq315">Orderable</td>
<td headers="wq316">N/A</td>
</tr>
<tr>
<td headers="wq311">5648-B33</td>
<td headers="wq312">AFP Font Collection for MVS</td>
<td headers="wq313">2.1.1</td>
<td headers="wq314">Orderable</td>
<td headers="wq315">Orderable</td>
<td headers="wq316">HFNT110</td>
</tr>
<tr>
<td headers="wq311">5648-B33</td>
<td headers="wq312">Japanese Fonts for MVS</td>
<td headers="wq313">2.1.1</td>
<td headers="wq314">Orderable</td>
<td headers="wq315">Orderable</td>
<td headers="wq316">HFNT11J</td>
</tr>
<tr>
<td headers="wq311">5648-B33</td>
<td headers="wq312">Korean Fonts for MVS</td>
<td headers="wq313">2.1.1</td>
<td headers="wq314">Orderable</td>
<td headers="wq315">Orderable</td>
<td headers="wq316">HFNT11J</td>
</tr>
<tr>
<td headers="wq311">5648-B33</td>
<td headers="wq312">T-Chinese Fonts for MVS</td>
<td headers="wq313">2.1.1</td>
<td headers="wq314">Orderable</td>
<td headers="wq315">Orderable</td>
<td headers="wq316">HFNT11J</td>
</tr>
<tr>
<td headers="wq311">5648-B33</td>
<td headers="wq312">S-Chinese Fonts for MVS</td>
<td headers="wq313">2.1.1</td>
<td headers="wq314">Orderable</td>
<td headers="wq315">Orderable</td>
<td headers="wq316">HFNT11J</td>
</tr>
<tr>
<td headers="wq311">5648-E76</td>
<td headers="wq312">General Font Library</td>
<td headers="wq313">1.1.0</td>
<td headers="wq314">Orderable</td>
<td headers="wq315">Orderable</td>
<td headers="wq316">HFNT110</td>
</tr>
<tr>
<td headers="wq311">5648-E76</td>
<td headers="wq312">T Chinese Font Library</td>
<td headers="wq313">1.1.0</td>
<td headers="wq314">Orderable</td>
<td headers="wq315">Orderable</td>
<td headers="wq316">HFNT11J</td>
</tr>
<tr>
<td headers="wq311">5648-E76</td>
<td headers="wq312">S Chinese Font Library</td>
<td headers="wq313">1.1.0</td>
<td headers="wq314">Orderable</td>
<td headers="wq315">Orderable</td>
<td headers="wq316">HFNT11J</td>
</tr>
<tr>
<td headers="wq311">5648-E76</td>
<td headers="wq312">Korean Font Library</td>
<td headers="wq313">1.1.0</td>
<td headers="wq314">Orderable</td>
<td headers="wq315">Orderable</td>
<td headers="wq316">HFNT11J</td>
</tr>
<tr>
<td headers="wq311">5648-E76</td>
<td headers="wq312">Japanese Font Library</td>
<td headers="wq313">1.1.0</td>
<td headers="wq314">Orderable</td>
<td headers="wq315">Orderable</td>
<td headers="wq316">HFNT11J</td>
</tr>
<tr>
<td headers="wq311">5771-ABC</td>
<td headers="wq312">Pi and Specials Fonts Object</td>
<td headers="wq313">1.1.1</td>
<td headers="wq314">Orderable</td>
<td headers="wq315">Orderable</td>
<td headers="wq316">HFNT110</td>
</tr>
<tr>
<td headers="wq311">5771-ADT</td>
<td headers="wq312">Math and Science Fonts Object</td>
<td headers="wq313">1.1.0</td>
<td headers="wq314">Orderable</td>
<td headers="wq315">Orderable</td>
<td headers="wq316">HFNT110</td>
</tr>
</tbody>
</table>
<p><a id="idx618"></a><a id="idx619"></a></p>
<table id="wq317" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>z/OS Font Collection</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td> Yes, if you use standalone program products
for fonts with your z/OS system.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: The z/OS Font Collection - for migration
compatibility with previously available font program products - will
continue to use SYS1.FONTLIB and SYS1.FONTLIBB.  IBM recommends you
use the latest level of the fonts available for z/OS, and therefore,
those that are found in the z/OS Font Collection.  For that reason,
do not continue to use the standalone font program product data sets
with z/OS releases after z/OS V1R13.  No application or program changes
are anticipated.</p>
<p>Do not expect to order separately available font program
products with z/OS V2R1, or to install them into the z/OS V2R1 SMP/E
zones.  The z/OS Font Collection provides SMP/E statements to supercede
and delete the prior standalone program product levels of the fonts.</p>
<p><strong>Reference information</strong>: For details about the z/OS
Font Collection, see <cite>z/OS Font Collection</cite><cite> z/OS
Font Summary</cite>. For installation planning information, see <cite>z/OS Planning
for Installation</cite>.</p>
<h3 id="e0z3m100-gen77">z/OS Base Font Collection actions to perform after the first
IPL of z/OS V2R1</h3><a id="idx620"></a>
<p>This topic describes z/OS Font Collection migration actions that
you can perform only after you have IPLed z/OS V2R1. You need a running
z/OS V2R1 system to perform these actions.</p>
<p>None.</p>
<h2 id="as1unss">z/OS UNIX migration
actions</h2>
<p>This topic describes migration actions for base element z/OS UNIX System
Services (z/OS UNIX).</p>
<h3 id="e0z3m100-gen151">z/OS UNIX actions to perform before installing z/OS
V2R1</h3><a id="idx621"></a>
<p>This topic describes z/OS UNIX migration actions that you
can perform on your current (old) system. You do not need the z/OS V2R1 level of code to make
these changes, and the changes do not require the z/OS V2R1 level of code to run once they are
made.</p>
<p><a href="e0z3m100.htm#hfs2zfs1">Migrate from HFS file systems to zFS file systems</a></p>
<p><a href="e0z3m100.htm#unixapi1">Ensure that your applications do not use removed z/OS UNIX
APIs</a></p>
<p><a href="e0z3m100.htm#dt2mg491">Determine whether to accept the new default values for certain
zFS variables in the zFS IOEFSPRM configuration file</a></p>
<p><a href="e0z3m100.htm#dt2mg492">Accommodate the new Shell and Utilities version of the zlsof
utility</a></p>
<h4 id="hfs2zfs1">Migrate from HFS file systems to zFS file systems</h4>
<p>[[[[ Contributing writer: Debra L Noll/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Ahilan Rajadeva/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: William Schoen/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Test contact: Robert Kindt/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R7,
the HFS file system was the primary hierarchical file system. As of
z/OS V1R7, you can use any combination of HFS and zFS file systems.
Because zFS has higher performance characteristics than HFS and is
the strategic file system, you should migrate your HFS file systems
to zFS.<a id="idx622"></a><a id="idx623"></a></p>
<p>The HFS and zFS file system types in mount statements and command
operands are now generic file system types that can mean either HFS
or zFS. Based on the data set type, the system will determine which
is appropriate. But note that you must still specify a type (HFS or
zFS and it cannot be defaulted), and if the type you specify is not
correct for the file system being mounted, any associated parameter
string setting in the mount statement or command is ignored, even
though the system sets the type correctly and processes the mount.</p>
<table id="wq318" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>zFS became the strategic file system in z/OS V1R7.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because the action is planned
to become a requirement in a future release. zFS is the strategic
file system for z/OS UNIX and
continues to be enhanced to provide superior performance, reliability,
and data integrity.

<p>z/OS V2R1 will support HFS file systems.</p></td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>
<ul>
<li>Understand the zFS recommendations and limits. For more information,
see "Minimum and maximum file system sizes" in <cite>z/OS Distributed File Service zFS Administration</cite> and <cite>z/OS Distributed File Service zFS Administration</cite></li>
<li>The DDNAME() keyword of the BPXPRMxx ROOT and MOUNT statements
is not supported by zFS. Use the FILESYSTEMNAME(<em>name</em>) keyword
instead.</li></ul></td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>Use check USS_HFS_DETECTED to verify all file
systems mounted. This check issues exception message BPXH068E if any
HFS file systems are found.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Before beginning the migration, do the following: 

<ul>
<li>Establish backout procedures.</li>
<li>Decide on naming conventions.</li>
<li>Decide on unavailability.</li>
<li>Understand any cloning or deployment changes required by zFS systems
being linear data sets. Considerations would include any copy utility
invocations, BPXPRMxx specifications for symbolics, and placement
of zFS file systems on system volumes.</li></ul></li>
<li>Perform the conversion from an HFS to zFS file system. 

<p><strong>Tip</strong>:
Use the BPXWH2Z tool to perform the conversion. It is an ISPF-based
tool that migrates HFS file systems to zFS file systems. Using its
panel interface, you can alter the space allocation, placement, SMS
classes, and data set names. A HELP panel is provided. With this tool,
you can: 
</p>
<ul>
<li>Migrate HFS file systems (both mounted and unmounted) to zFS file
systems. If the HFS being migrated is mounted, the tool automatically
unmounts it and then mounts the new zFS file system on its current
mount point.</li>
<li>Define zFS aggregates by default to be approximately
the same size as the  HFS. The new allocation size can also be increased
or decreased. In z/OS V1R13, ZFS could require up to four times (4X)
the space that HFS did; therefore, for z/OS V2R1 be sure to allocate
more space. See <a href="e0z3m100.htm#newdasd">zFS: Accommodate new DASD space requirements</a>.</li>
<li>Have the migration run in TSO foreground or UNIX background.</li></ul> 

<p>You can use the JCL sample ISPBTCH in SYS1.SAMPLIB
to invoke BPXWH2Z as an ISPF batch job. Before you run the job, read
the <strong>Notes</strong> section. When you run BPXWH2Z on your z/OS system,
make sure it uses that same z/OS level of the pax command. You can
manually migrate from an HFS to zFS file system without using the
tool. However, you would need to allocate and format the target zFS
file systems.</p> 

<p><strong>Requirement</strong>: The BPXWH2Z tool requires
the zFS address space to be operational. Therefore, before attempting
to migrate existing HFS to zFS file systems using BPXWH2Z, make sure
that the zFS address space has been successfully configured and initialized.</p> 

<p><strong>Tip</strong>: You can dynamically migrate the HFS sysplex root
in a shared file system configuration to zFS while the root is in
use, without disrupting workloads. Although the shared file system
configuration is required, the sysplex can be a single system. For
the steps involved in migrating the sysplex root file system from
HFS to zFS, see below.</p></li>
<li>Change policies and scripts, and so forth, to reflect
the change from the HFS file system to zFS file system. Use the RMF
Monitor III option to report on zFS activity. Refer to migration action
"Monitor the zFS file system activity" for information on gathering
zFS activity in RMF Monitor III. 

<p><strong>Tip</strong>: Use the RMF Monitor III option to report on zFS activity.</p>
<div>
<div class="note-noindent" id="wq320">
<span class="notetitle">Note:</span> <span class="notebody">Beginning
in z/OS V2R1, the default of RMF Monitor III option was changed to
NOZFS. So, you need to explicitly specify ZFS option.</span></div></div></li>
<li>he DDNAME(<em>name</em>) keyword of the BPXPRMxx ROOT and
MOUNT statements is not supported by zFS. If you use them. change
these statements to use the FILESYSTEMNAME(<em>name</em> keyword instead.</li></ol>
<p id="hfs2zfs1__rootmig1"><strong>Migrating the sysplex root file system from HFS
to zFS after IPL of z/OS</strong>:</p>
<p><a id="idx624"></a>Before
you begin the migration: 
</p>
<ul>
<li>Ensure that the following requirements have been met: 

<ul>
<li>The current sysplex root file system PFS, and the new sysplex
root file system PFS, are up in all the systems in shared file system
configuration.</li></ul></li>
<li>Be aware of the following restrictions: 

<ul>
<li>The current sysplex root file system must be mounted as a read-only
file system.</li>
<li>The systems that do not meet the requirements for this migration
action cannot join the sysplex during the sysplex root file system
migration processing, but they can join the sysplex after the sysplex
root migration has completed.</li>
<li>The current sysplex root and the new sysplex root must be either
HFS or zFS in any combination. If the new sysplex root is zFS, then
 it must be HFS-compatible.</li>
<li>The sysplex root or any directories on it cannot have been exported
by the DFS or
SMB server.</li></ul></li>
<li>Note the following: 

<ul>
<li>Remote NFS mounts of the sysplex root or any directories on it
are considered active use of the current sysplex root file system.</li>
<li>During the migration, the new zFS sysplex root file system must
not be HSM-migrated, mounted, or in use.</li>
<li>Mount parameters are preserved during the migration or replacement
of the sysplex root file system of the same file system type (PFS).
They are dropped if the file system type is different.</li>
<li>Directories, data, files, and links are not copied from one file
system to another.</li></ul></li></ul>
<p>Perform the migration as follows:</p>
<ol type="1">
<li>Ensure that a file system has been mounted read-only as the current
sysplex root file system. When the root is mounted read-only, there
are no function-shipping clients as long as physical paths to the
DASD are available to each system. To verify that there are no function-shipping
clients, issue:  
<pre class="xmp"><code>D OMVS,F,NAME=root_file_system_name</code></pre> You
should see CLIENT=N on each system.</li>
<li>Allocate and set up the new zFS sysplex root file system:  

<ol type="a">
<li>Create a new zFS file system to be used as the new sysplex root
file system. <cite>z/OS Distributed File Service zFS Administration</cite> discusses
creating and managing zFS file systems.  

<p><strong>Rules</strong>:
 
</p>
<ul>
<li>The UID, GID and the permission bits of the root directory in
the new sysplex root file system must be same as the root directory
in the current sysplex root file system.</li>
<li>If the SECLABEL class is active and the MLFSOBJ option is active,
the security label for the new zFS file system must match the assumed
security label of the current sysplex root file system.</li></ul></li>
<li>On the new sysplex root file system, set up the active mount points
and the symbolic links. The mount points and symbolic links must be
the same as the ones on the current sysplex root file system. You
can set them up either (1) manually or (2) by using the <span class="synph"><span class="kwd">pax</span></span> shell
command to populate the new sysplex root file system using the existing
sysplex root as a source. To do it manually, create a mount point
in the existing sysplex root (for example, /newroot) and mount the
new sysplex root file system in the MODE(RDWR) on that mount point.
After mounting the new sysplex root file system, manually issue MKDIRs
and ln -s to create the mount point directories and symbolic links
similar to the existing sysplex root file system. Note that the new
sysplex root file system must contain all active mount points and
symbolic links exactly as on the existing sysplex root file system.</li>
<li>Use the <span class="synph"><span class="kwd">pax</span></span> shell command to populate
the new file system, using the existing sysplex root as a
source. 

<p><strong>Example</strong>:  </p>
<pre class="xmp"><code>cd /
pax -wr -pe -XCM ./ /newroot</code></pre><p class="indatacontent"> For more information about
using <span class="synph"><span class="kwd">pax</span></span> to copy data from an HFS file
system to a zFS file system, see <cite>z/OS Distributed File Service zFS Administration</cite>.</p></li>
<li>Unmount the new zFS file system.</li></ol></li>
<li>On any system in the shared file system configuration, issue: 
<pre class="xmp"><code>F OMVS,NEWROOT=new.root.file.system.name,COND=&lt;Yes|No&gt;</code></pre>  

<dl>
<dt class="bold">YES</dt>
<dd>Proceed conditionally. The system checks for active usage in the
current sysplex root file system and reports the active usage in a
BPXF245I message. If file activity is found, the command fails
with EBUSY return code and JrActivityFound reason code. If file activity
is not found, the command continues processing to replace the sysplex
root. YES is the default.
</dd>
<dt class="bold">NO</dt>
<dd>Proceed unconditionally. The system checks for active usage in
the current sysplex root file system and reports the active usage
in a BPXF245I message. Replacement of the sysplex root file
system will continue.
</dd>
</dl>The migration of  the sysplex root file system will
begin. During the migration, active connections to files and directories
in the current sysplex root file system are broken. 

<p>After the migration
completes:</p> 

<ul>
<li>The root CWD(&lsquo;/&rsquo;) is updated on all systems in the sysplex to
point to the new sysplex root file system.</li>
<li>New opens go to the new sysplex root file system.  The current
sysplex root for the root directory is replaced for all  processes
in all systems.  The current directory for root directory is replaced
for any processes using it</li>
<li>Old connections in the previous sysplex root file system might get
EIO errors.</li></ul></li>
<li>Update the TYPE parameter and name of the sysplex root
file system in the BPXPRM<span class="synph"><span class="var">xx</span></span> member of SYS1.PARMLIB.</li>
<li>Because the DDNAME() keyword of the BPXPRMxx ROOT and
MOUNT statements is not supported by zFS, change these statements
to use the FILESYSTEMNAME(<em>name</em>) keyword instead.</li></ol>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li>For more information about the HFS and zFS file systems, see <cite>z/OS UNIX System Services Planning</cite>.</li>
<li>To read about setting up zFS, see <cite>z/OS Distributed File Service zFS Administration</cite>.</li>
<li>For information about the <strong>pax</strong> command, see <cite>z/OS UNIX System Services Command Reference</cite>.</li></ul>
<h4 id="unixapi1">Ensure that your applications do not use removed z/OS UNIX
APIs</h4><a id="idx625"></a><a id="idx626"></a><a id="idx627"></a><a id="idx628"></a>
<p>[[[[ Debbie Noll: ]]]] [[[[ Duane Hughes]]]]</p>
<p><strong>Description</strong>: Before z/OS V2R1, certain z/OS UNIX application
programming interfaces (APIs) were available. Starting in z/OS V2R1,
they are no longer available. <a id="idx629"></a></p>
<table id="wq323" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your installation has C/C++ or Assembler
language applications that explicitly invoke z/OS UNIX application
programming interfaces.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>This change does not affect the z/OS system
itself but might cause applications or products other than z/OS to
give erroneous results or behave unexpectedly.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Check three interfaces to see if the removed
services are being used.</p>
<ol type="1">
<li>Scan the source code for use of the following z/OS UNIX application
programming interfaces: 

<ul>
<li>The _osenv() syscall 

<ul>
<li>For Assembler language programs, search for BPX1OSE and BPX4OSE.</li>
<li>For C or C++ code, search for calls to the _osenv() service.</li></ul></li>
<li>The pthread_quiesce_and_get_np() syscall 

<ul>
<li>For Assembler language programs, search for BPX1PQG and BPX4PQG.</li>
<li>For C or C++ code, search for calls to the pthread_quiesce_and_get_np()
service.</li></ul></li>
<li>The QUICK_FREEZE_EXIT_REG option of oe_env_np() 

<ul>
<li>For Assembler language programs, search for BPX1ENV and BPX4ENV.</li>
<li>There is no C/C++ interface that allows direct use of the QUICK_FREEZE_EXIT_REG
option. If you find use of the BPX1ENV or BPX4ENV service, check whether
the QUICK_FREEZE_EXIT_REG option is specified. If you do use this
option, verify that you have code that invokes the pthread_quiesce_and_get_np()
service (in XL C/C++) or calls BPX1PQG or BPX4PQG. If you do not have
code that calls the pthread_quiesce_and_get_np() service, then you
do not need to invoke the BPX1ENV or BPX4ENV service with the QUICK_FREEZE_EXIT_REG
option. Remove that call from your application.</li></ul></li></ul></li>
<li>If your applications use any of these interfaces, update the applications
to either eliminate the calls or handle the new return code and reason
code that the removed interfaces will return.</li></ol>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li><cite>z/OS UNIX System Services Programming: Assembler Callable Services Reference</cite></li>
<li><cite>z/OS XL C/C++ Runtime Library Reference</cite></li></ul>
<h4 id="dt2mg491">Determine whether to accept the new default values for certain
zFS variables in the zFS IOEFSPRM configuration file</h4><a id="idx630"></a>
<p></p>
<p><strong>Description</strong>: Before z/OS V2R1, certain default values were
used for the IOEFSPRM files or IOEPRMxx parmlib member variables <samp>meta_cache_size</samp>, <samp>metaback_cache_size</samp>, <samp>user_cache_size</samp>,
or <samp>convert_auditfid</samp>. Starting in z/OS V2R1, new default
values are created for them.</p>
<table id="wq325" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you do not want to continue accepting
the default values for the zFS configuration variables or if you have
provided values for these configuration variables.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>If enough real storage exists, zFS can use more
storage by default than it would have used in prior releases.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:
</p>
<ul>
<li>Look for these:

<ul>
<li>IOEFSPRM files or IOEPRMxx parmlib members that do not specify
both <samp>meta_cache_size</samp> and <samp>metaback_cache_size</samp> options.</li>
<li>IOEFSPRM files or IOEPRMxx parmlib members that do not specify
the <samp>user_cache_size</samp> option.</li>
<li>IOEFSPRM files or IOEPRMxx parmlib members that do not specify <samp>convert_auditfid</samp> settings.</li>
<li>Programs that use <strong><samp>zfsadm format</samp></strong> commands where
unique auditfids are not desired.</li>
<li>JCL that contains calls to<strong><samp> ioeagfmt</samp></strong> that create
aggregates for which unique auditfids are not desired.</li>
<li>Programs that use zFS format API where unique auditfids are not
desired.</li></ul></li>
<li>Take these actions:

<ul>
<li>For <samp>meta_cache_size</samp>, <samp>metaback_cache_size</samp>,
or <samp>user_cache_size</samp>, if the old default values are
desired, specify these values in your IOEFSPRM files or IOEPRMxx parmlib
members.</li>
<li>For auditfid, if you want the previous defaults, specify <samp>-nonewauditfid</samp> on
calls to <strong><samp>ioeagfmt</samp></strong> or <strong><samp>zfsadm format</samp></strong> and <samp>convert_auditfid=OFF</samp> in
your IOEFSPRM files or IOEPRMxx parmlib members.</li></ul></li></ul>
<p><strong>Reference information</strong>: For more information about zFS, see<cite>z/OS Distributed File Service zFS Administration</cite>.</p>
<h4 id="dt2mg492">Accommodate the new Shell and Utilities version of the zlsof
utility</h4><a id="idx631"></a>
<p></p>
<p><strong>Description</strong>: Before
z/OS V2R1, the <strong><samp>zlsof</samp></strong> utility was obtained from
the Tools and Toys section of the z/OS UNIX website. Starting in z/OS
V2R1, Shell and Utilities support of the <strong><samp>zlsof</samp></strong> utility
has been added. The supported version differs from the Tools and Toys
version in a number of ways. For example, the new <strong><samp>zlsof</samp></strong> 
version includes support for displaying file lock holders and waiters
when the byte range lock manager is used.:</p>
<table id="wq326" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you currently use the Tools and Toys
version of the <strong><samp>zlsof</samp></strong> utility.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Look for current use of the Tools and Toys
version of <strong><samp>zlsof</samp></strong>. If there is no current use of
the Tools and Toys version of <strong><samp>zlsof</samp></strong>, then no actions
or changes are required.</p>
<p>If there is current usage of the Tools and Toys version of <strong><samp>zlsof</samp></strong>,
determine if the command is in <samp>/bin</samp>, or in another
directory. Also, determine if you want to preserve the Tools and Toys
version in addition to the officially shipped version. Note that <strong><samp>zlsof</samp></strong> can
also reside in data sets where rexx execs can be run.
</p>
<ol type="1">
<li>If you want to preserve the Tools and Toys version, ensure
that you save it into a directory that z/OS V2R1 will not install
into. z/OS V2R1 provides <strong><samp>zlsof</samp></strong> in the <samp>/bin</samp> directory.</li>
<li id="xfmtmark-gen1__zlstep">If you do not want to preserve the Tools and Toys
version and it is in <samp>/bin</samp>, then the installation
of z/OS V2R1 automatically replaces the Tools and Toys version with
the new officially supported version.  If the Tools and Toys version
is not in <samp>/bin</samp>, remove it from its current location.</li></ol>
<p><strong>Reference information:</strong> For details about the <strong><samp>zlsof</samp></strong> command,
see <cite>z/OS UNIX System Services Command Reference</cite>.</p>
<h3 id="e0z3m100-gen79">z/OS UNIX actions to
perform before the first IPL of z/OS V2R1</h3>
<p>This topic describes z/OS UNIX migration actions that you
can perform after you have installed z/OS V2R1 but before the first
time you IPL. These actions might require th z/OS V2R1 level of code
to be installed but do not require it to be active.<a id="idx632"></a><a id="idx633"></a><a id="idx634"></a><a id="idx635"></a><a id="idx636"></a><a id="idx637"></a></p>
<p><a href="e0z3m100.htm#smf921">Update applications that use SMF type 92 subtype 11 close records</a></p>
<p><a href="e0z3m100.htm#dt2mg497">Remove ICLI component from z/OS</a></p>
<p><a href="e0z3m100.htm#dt2mg499">Determine if any sticky bit files or external links in your
z/OS UNIX file system are involved with link-edited MVS programs with
AC=1 (Part 1 before the first IPL of V2R1)</a></p>
<h4 id="smf921">Update applications that use SMF type 92 subtype 11 close records</h4>
<p>[[[[ Debbie Noll: ]]]] [[[[ Daniel Acevedo]]]]</p>
<p><strong>Description</strong>: Before z/OS V2R1, SMF type 92, subtype
11 close records were written when sockets or character special records
were closed. Sockets and character special files have very high close
rates and do not provide useful information in determining how often
files and directories are used. Starting in z/OS V2R1, they are written
as subtype 16 close records instead. The sockets and character special
file close records will no longer appear in type 92 subtype 11 records.
Instead, you need to include type 92 subtype 16 records in the SMFPRMxx
parmlib member to collect them.<a id="idx638"></a></p>
<table id="wq328" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Beforethe first IPL z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want continue to get close records
for sockets and character special files.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Determine whether you have applications that use SMF type 92 subtype
11 close records. For those applications, SMF92TYP is set to SMF92#CLOSE
(11) for subtype 11. SMF92CTY is set to FT_SOCKET (7) for sockets
and FT_CHARSPEC (2) for character special files.</li>
<li>Change the application to look at subtype 16 records. SMF92TYP
will be set to SMF92#CLSSOCCHARSPEC (16).</li></ol>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li><cite>z/OS UNIX System Services Planning</cite></li></ul>
<h4 id="dt2mg497">Remove ICLI component from z/OS</h4><a id="idx639"></a><a id="idx640"></a>
<p>[[[[ Contributing writer: Jim Guilianelli]]]]
[[[[ Original technical contact: Greg Callis/Raleigh/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: IBM intends to remove the Integrated Call Level
Interface (ICLI) in z/OS z/OS V2R1. ICLI is used by those who have
requested and obtained the ICLI API documentation and the C language
header file. IBM believes that users of this interface have changed
from using ICLI to standard IBM DB2 Connect for database connectivity
and do not need it when z/OS V2R1 becomes available. ICLI has not
been enhanced since z/OS 1.6. IBM intends to exclude ICLI from releases
after z/OS V1R13.</p>
<p>Also see <a href="e0z3m100.htm#dt2mg340">IP Services: Remove ICLI component from z/OS</a>.</p>
<table id="wq330" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td align="left">Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because ICLI is planne dto
be removed in a future release.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>ZOSMIGV2R1_CS_GATEWAY can help you determine
if you are using any GATEWAY statements in your TCP/IP profile.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Remove the ICLI component. To identify the
ICLI components examine the ibmicli.h header file?????????? Contact
your IBM representative if you have questions?</p>
<p><strong>Reference information:</strong> None.</p>
<h4 id="dt2mg499">Determine if any sticky bit files or external links in your
z/OS UNIX file system are involved with link-edited MVS programs with
AC=1 (Part 1 before the first IPL of V2R1)</h4><a id="idx641"></a>
<p> [[[[ Contributing writer: Debra L Noll/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Mike Spiegel/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Starting in z/OS V2R1, the invocation requirements
for MVS load library programs invoked through the z/OS UNIX spawn,
exec and attach_exec services have changed. These changes apply to
the invocation of MVS programs link-edited AC=1 found in an APF-authorized
library and for MVS load library programs that are to run as a z/OS
UNIX set-user-id or set-group-id program.  The following list describes
the changes: 
</p>
<ul>
<li>If the z/OS UNIX <em>pathname</em> that is supplied
to spawn,  exec or attach_exec represents an external link that resolves
to an MVS program found in an APF-authorized library and link-edited
with the AC=1 attribute, the external link must have an owning UID
of 0 and not be found in a file system that is mounted as NOSECURITY
to allow this type of invocation.</li>
<li>If the z/OS UNIX <em>pathname</em>  that is supplied
to spawn, exec, or attach_exec represents a regular file with the
sticky bit attribute that resolves to an MVS program found in an APF-authorized
library and link-edited with the AC=1 attribute, the sticky bit file
must have an owning UID of 0 or have the APF extended attribute turned
on to allow this type of invocation. Additionally, the sticky bit
file must not be found in a file system that is mounted as NOSECURITY
to allow this type of invocation.</li>
<li>If the z/OS UNIX <em>pathname</em> that supplied to
spawn, exec or attach_exec represents a symbolic link to a regular
file with the sticky bit attribute and the sticky bit file has the
set-user-id attribute, the symbolic link must have an owning UID of
0 or an owning UID equal to that of the sticky bit file.  If the sticky
bit file has the set-group-id attribute, the symbolic link must have
an owning UID of 0 or an owning GID equal to that of the sticky bit
file. Additionally, the symbolic link must not be found in a file
system that is mounted as NOSECURITY to allow this type of invocation.</li></ul>
<table id="wq331" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12  without APAR OA41101
applied.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of V2R1. (For steps to
take after the first IPL of z/OS V2R1, see .)</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended even though most, if not
all, IBM and vendor products install their executable files into the
z/OS UNIX file system with an owning UID of 0, so few, if any, executable
files on a customer system should have a problem.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>See <strong>Steps to take</strong>.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take before the first IPL</strong>: If you are
migrating a z/OS system from z/OS V1R12 or z/OS V1R13 with APAR OA41101
installed, then no migration actions need to be taken.   In this case,
it is assumed that you have taken all required actions related to
this APAR. Also see the documentation APAR OA41490.</p>
<p>If you are migrating from a z/OS system that does not have OA41101
installed and use the following IBM products, then you should ensure
that you have the latest service levels and have followed the most
recent install documentation for these IBM products:
</p>
<ul>
<li>IBM z/OS Problem Determination Tools File Manager Software V10
(see Doc APAR PM81080)</li>
<li>IBM z/OS Problem Determination Tools File Manager Software V11.1.0
with upgrade subset HADLB10 (ensure that PTF UK91613 is installed)</li>
<li>IBM z/OS Problem Determination Tools Common Component Software
V1.6.0 with upgrade subset HVWR160 (ensure that PTF UK91612 is installed)</li>
<li>IBM InfoSphere Data Replication (see Doc APAR PM81306)</li>
<li>IBM Security zSecure Suite (See Technote 1625364)</li>
<li>IBM Tivoli Security Information and Event Manager (see Technote
1626384)</li></ul>
<p>You may have to change the installation of some z/OS UNIX files
and links provided by these products.</p>
<p>Otherwise, if you follow the standard install process for z/OS
UNIX software, then you should not need to make any further changes
related to APAR OA41101. Exceptions to this would be: 
</p>
<ul>
<li>If you installed z/OS UNIX sticky bit files, symbolic links or
external links for any of your own software without using SMP/E</li>
<li>If you installed any IBM or other vendor provided z/OS UNIX sticky
bit files, symbolic links or external links outside the normal SMP/E
install process</li>
<li>If you installed z/OS UNIX software using SMP/E from a user that
is not running with UID 0 and is not permitted to BPX.SUPERUSER</li></ul>
<p>If any of these exceptions exist on your system, then you might
have to change the installation of these files and links.   To identify
all the sticky bit files, symbolic links and external links that need
to change, you need to IPL with z/OS V2R1 installed.   If any of these
files or links are executed,  you will then start seeing  EC6-xxxxC04A
abends along with message BPXP028I in the system log, which identifies
the files or links that must be changed.    You can then use the documentation
for message BPXP028I to correct the files or links that are installed
improperly.  For more information about message BPXP028I, see <cite>z/OS MVS System Messages, Vol 3 (ASB-BPX),</cite>.</p>
<p>For steps to take after the first IPL, see <a href="e0z3m100.htm#dt2mg502">Determine if any sticky bit files or external links in your
z/OS UNIX file system are involved in the invocation of MVS programs
that are link-edited with the AC=1 attribute (Part 2 after IPL of
z/OS V2R1)</a></p>
<p><strong>Reference information:</strong> <cite>z/OS UNIX System Services Command Reference</cite>.</p>
<h3 id="e0z3m100-gen80">z/OS UNIX actions to
perform after the first IPL of z/OS V2R1</h3>
<p>This topic describes z/OS UNIX migration
actions that you can perform only after you have IPLed z/OS V2R1.
You need a running z/OS V2R1 system to perform these actions.</p>
<h4 id="dt2mg502">Determine if any sticky bit files or external links in your
z/OS UNIX file system are involved in the invocation of MVS programs
that are link-edited with the AC=1 attribute (Part 2 after IPL of
z/OS V2R1)</h4><a id="idx642"></a>
<p></p>
<p><strong>Description</strong>: Starting in z/OS V2R1, the invocation requirements
for MVS load library programs invoked via the z/OS UNIX spawn, exec
and attach_exec services have changed.   These changes apply to the
invocation of MVS programs link-edited AC=1 found in an APF-authorized
library and for MVS load library programs that are to run as a z/OS
UNIX set-user-id or set-group-id program.  The following list describes
the changes: 
</p>
<ul>
<li>If the z/OS UNIX <em>pathname</em> that is supplied
to spawn,  exec or attach_exec represents an external link that resolves
to an MVS program found in an APF-authorized library and link-edited
with the AC=1 attribute, the external link must have an owning UID
of 0 and not be found in a file system that is mounted as NOSECURITY
to allow this type of invocation.</li>
<li>If the z/OS UNIX <em>pathname</em>  that is supplied
to spawn, exec, or attach_exec represents a regular file with the
sticky bit attribute that resolves to an MVS program found in an APF-authorized
library and link-edited with the AC=1 attribute, the sticky bit file
must have an owning UID of 0 or have the APF extended attribute turned
on to allow this type of invocation. Additionally, the sticky bit
file must not be found in a file system that is mounted as NOSECURITY
to allow this type of invocation.</li>
<li>If the z/OS UNIX <em>pathname</em> that supplied to
spawn, exec or attach_exec represents a symbolic link to a regular
file with the sticky bit attribute and the sticky bit file has the
set-user-id attribute, the symbolic link must have an owning UID of
0 or an owning UID equal to that of the sticky bit file.  If the sticky
bit file has the set-group-id attribute, the symbolic link must have
an owning UID of 0 or an owning GID equal to that of the sticky bit
file. Additionally, the symbolic link must not be found in a file
system that is mounted as NOSECURITY to allow this type of invocation.</li></ul>
<table id="wq332" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12 without APAR OA41101
applied.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V2R1. (For steps
to take before the first IPL, see <a href="e0z3m100.htm#dt2mg499">Determine if any sticky bit files or external links in your
z/OS UNIX file system are involved with link-edited MVS programs with
AC=1 (Part 1 before the first IPL of V2R1)</a>).</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended even though most, if not
all, IBM and vendor products install their executable files into the
z/OS UNIX file system with an owning UID of 0, so few, if any, executable
files on a customer system should have a problem.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take after the first IPL</strong>: If you see EC6-xxxxC04A
abends occurring, look for message BPXP028I in the system log to determine
the details of the z/OS UNIX files or links and MVS programs involved
with the errors and how to correct the problem. This abend is indicative
of an attempt to execute an improperly installed z/OS UNIX sticky
bit file, symbolic link or external link that resolves to a MVS program.
 For more information about message BPXP028I, see <cite>z/OS MVS System Messages, Vol 3 (ASB-BPX),</cite>.</p>
<p>For <strong>Steps to take before the first IPL</strong>, see <a href="e0z3m100.htm#dt2mg499">Determine if any sticky bit files or external links in your
z/OS UNIX file system are involved with link-edited MVS programs with
AC=1 (Part 1 before the first IPL of V2R1)</a>.</p>
<p><strong>Reference information:</strong> .</p>
<h4 id="bpxuniq">Use the BPX.UNIQUE.USER profile instead of BPX.DEFAULT.USER</h4><a id="idx643"></a><a id="idx644"></a><a id="idx645"></a><a id="idx646"></a><a id="idx647"></a><a id="idx648"></a>
<p>[[[[ Contributing writer: Debra L Noll/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: John Helmbold/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>:  Before z/OS V1R11,
if the BPX.DEFAULT.USER profile in the FACILITY class was defined,
users who accessed z/OS UNIX services who did not have
an OMVS user or group segment were assigned the default OMVS segments
for the length of the user session. All users of the default OMVS
segments shared the same UID and GID. As of z/OS V1R11, if BPX.UNIQUE.USER has been defined,
users who access z/OS UNIX services
who do not have an OMVS user or group segment are automatically assigned
an OMVS segment with a unique UID and GID. The new OMVS segments are
added to the user and group profiles in the RACF database.<a id="idx649"></a><a id="idx650"></a></p>
<table id="wq333" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1. Function introduced in z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes because z/OS V1R13 is planned to be the
last release to support BPX.DEFAULT.USER (as previewed in z/OS
V1R13 Software Announcement 211-007, dated February 15, 2011).
IBM recommends that you either use the BPX.UNIQUE.USER support, or
assign unique UIDs to users who need them and assign GIDs for their
groups. The use of BPX.UNIQUE.USER increases security because shared
IDs are not used.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Follow the steps in <cite>z/OS UNIX System Services Planning</cite> to
set up the BPX.UNIQUE.USER profile. If BPX.DEFAULT.USER has not been
deleted, BPX.UNIQUE.USER takes precedence when default OMVS segments
are used. This migration action is mandatory when migrating to z/OS
V2R1 from z/OS V1R12 or z/OS V1R13.</p>
<p>To remove the BPX.DEFAULT.USER profile, use the following RACF commands: </p>
<pre class="xmp"><code>RDELETE FACILITY BPX.DEFAULT.USER 
SETROPTS RACLIST(FACILITY) REFRESH</code></pre>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li><cite>z/OS UNIX System Services Planning</cite></li>
<li><cite>z/OS Security Server RACF Security Administrator&amp;apos;s Guide</cite></li></ul>
<h1 id="rel1">Migration from z/OS V1R12</h1>
<div>
<p>Part 3 describes those actions for anyone who is migrating
from z/OS V1R12.</p></div>
<p>REVIEWERS: PLEASE ENTER YOUR REVIEW
COMMENTS FOR MIGRATION ACTIONS IN THIS CHAPTER. IT INCLUDES ALL MIGRATION
ACTIONS THAT APPLY TO BOTH V1R13 ANDF V1R12 CUSTOMERS MOVING TO V2R1
AS WELL AS THOSE ACTIONS THAT APPLY ONLY TO MOVING FROM V1R12 TO V2R1.</p>
<p>ANY COMMENTS YOU MAKE IN THIS CHAPTER
FOR V1R13 AND V1R12 APPLY TO THE CORRESPONDING ACTIONS IN CHAPTER
2.</p>
<h2 id="av1pars11">Sysplex migration actions</h2>
<p>This topic summarizes actions for you to take if you are migrating
systems that are members of a base sysplex or Parallel Sysplex configuration.</p>
<h3 id="dt2mg521">Sysplex actions related to hardware upgrades</h3><a id="idx651"></a>
<table id="wq334" width="100%" summary="" border="1" frame="border" rules="all">
<thead valign="bottom">
<tr>
<th id="wq335" width="75%" align="left" valign="top">Title of migration action</th>
<th id="wq336" width="25%" align="left" valign="top">Page or topic</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq335"><a href="e0z3m100.htm#au3cpfl">Update your CFRM policy with coupling facility structure size
changes</a></td>
<td headers="wq336"><a href="e0z3m100.htm#au3cpfl">Update your CFRM policy with coupling facility structure size
changes</a></td>
</tr>
<tr>
<td headers="wq335"><a href="e0z3m100.htm#mignext">Migrate to an IBM zEnterprise z196 or z114 server</a></td>
<td headers="wq336"><a href="e0z3m100.htm#mignext">Migrate to an IBM zEnterprise z196 or z114 server</a></td>
</tr>
<tr>
<td headers="wq335"><a href="e0z3m100.htm#migrz10">Migrate to a System z10 server</a></td>
<td headers="wq336"><a href="e0z3m100.htm#migrz10">Migrate to a System z10 server</a></td>
</tr>
</tbody>
</table>
<h3 id="e0z3m100-gen95">Sysplex actions to perform before installing z/OS V2R1</h3><a id="idx652"></a><a id="idx653"></a><a id="idx654"></a><a id="idx655"></a><a id="idx656"></a>
<table id="wq337" width="100%" summary="" border="1" frame="border" rules="all">
<thead valign="bottom">
<tr>
<th id="wq338" width="12%" align="left" valign="bottom">Element or feature</th>
<th id="wq339" width="57%" align="left" valign="bottom">Title of migration action</th>
<th id="wq340" width="29%" align="left" valign="bottom">Page or topic</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq338">Multiple</td>
<td headers="wq339"><a href="e0z3m100.htm#coxptfs">Install coexistence and fallback PTFs</a></td>
<td headers="wq340"><a href="e0z3m100.htm#coxptfs">Install coexistence and fallback PTFs</a></td>
</tr>
<tr>
<td headers="wq338">DFSMSdfp</td>
<td headers="wq339"><a href="e0z3m100.htm#ax3eisc1">DFSMSdfp:
Back up SMS control data sets</a></td>
<td headers="wq340"><a href="e0z3m100.htm#ax3eisc1">DFSMSdfp:
Back up SMS control data sets</a></td>
</tr>
<tr>
<td headers="wq338">Distributed File Service</td>
<td headers="wq339"><a href="e0z3m100.htm#filesyszfs">zFS: Ensure sysplex=filesys is available on all zFS R11 and
R12 systems in a shared file system environment</a></td>
<td headers="wq340"><a href="e0z3m100.htm#filesyszfs">zFS: Ensure sysplex=filesys is available on all zFS R11 and
R12 systems in a shared file system environment</a></td>
</tr>
</tbody>
</table>
<h3 id="e0z3m100-gen96">Sysplex actions to perform before the first IPL of z/OS V2R1</h3>
<p>None.</p>
<p></p>
<table id="wq341" width="100%" summary="" border="1" frame="border" rules="all">
<thead valign="bottom">
<tr>
<th id="wq342" width="11%" align="left" valign="bottom"><a id="idx657"></a><a id="idx658"></a><a id="idx659"></a><a id="idx660"></a><a id="idx661"></a><a id="idx662"></a><a id="idx663"></a>Element
or feature</th>
<th id="wq343" width="70%" align="left" valign="bottom">Title of migration action</th>
<th id="wq344" width="18%" align="left" valign="bottom">Page or topic</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq342">BCP</td>
<td headers="wq343"><a href="e0z3m100.htm#oa35357">Change value for ARM restart processing</a></td>
<td headers="wq344"><a href="e0z3m100.htm#oa35357">Change value for ARM restart processing</a></td>
</tr>
<tr>
<td headers="wq342">BCP</td>
<td headers="wq343"><a href="e0z3m100.htm#dxcfmsg">Modify automation that references output from D XCF,SYSPLEX
console commands</a></td>
<td headers="wq344"><a href="e0z3m100.htm#dxcfmsg">Modify automation that references output from D XCF,SYSPLEX
console commands</a></td>
</tr>
<tr>
<td headers="wq342">BCP</td>
<td headers="wq343"><a href="e0z3m100.htm#operloge">Accommodate OPERLOG EMCS console name change</a></td>
<td headers="wq344"><a href="e0z3m100.htm#operloge">Accommodate OPERLOG EMCS console name change</a></td>
</tr>
<tr>
<td headers="wq342">JES3</td>
<td headers="wq343"><a href="e0z3m100.htm#autoflsh">Avoid redundant *S main,FLUSH command in response to XCF messages</a></td>
<td headers="wq344"><a href="e0z3m100.htm#autoflsh">Avoid redundant *S main,FLUSH command in response to XCF messages</a></td>
</tr>
</tbody>
</table>
<h3 id="e0z3m100-gen97">Sysplex actions to perform after the first IPL of z/OS V2R1</h3>
<p>None.</p>
<table id="wq345" width="100%" summary="" border="1" frame="border" rules="all">
<thead valign="bottom">
<tr>
<th id="wq346" width="11%" align="left" valign="bottom"><a id="idx664"></a><a id="idx665"></a><a id="idx666"></a><a id="idx667"></a><a id="idx668"></a><a id="idx669"></a><a id="idx670"></a>Element
or feature</th>
<th id="wq347" width="60%" align="left" valign="bottom">Title of migration action</th>
<th id="wq348" width="28%" align="left" valign="bottom">Page or topic</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq346">BCP</td>
<td headers="wq347"><a href="e0z3m100.htm#grsficon1">Migrate to GRS-managed FICON CTCs</a></td>
<td headers="wq348"><a href="e0z3m100.htm#grsficon1">Migrate to GRS-managed FICON CTCs</a></td>
</tr>
<tr>
<td headers="wq346">SDSF</td>
<td headers="wq347"><a href="e0z3m100.htm#wbmqsdsf">Update configuration for sysplex support</a></td>
<td headers="wq348"><a href="e0z3m100.htm#wbmqsdsf">Update configuration for sysplex support</a></td>
</tr>
</tbody>
</table>
<h2 id="aa1bcp1">BCP migration actions</h2>
<p>This topic describes migration actions for the base element BCP
(Base Control Program).</p>
<h3 id="dt2mg523">BCP actions to perform before installing z/OS V2R1</h3><a id="idx671"></a>
<p>This topic describes BCP migration actions that you can perform
on your current (old) system. You do not need the z/OS V2R1 level of code to make these changes,
and the changes do not require the z/OS V2R1
level of code to run once they are made.</p>
<p>PLACEHOLDER FOR POSSIBLE WLM ACTION</p>
<p><a href="e0z3m100.htm#edumpds">Evaluate your stand-alone dump data set allocations and your
IPCS processing of them</a></p>
<p><a href="e0z3m100.htm#switch_id">Move from the Consoles Tracking Facility to the Generic Tracker</a></p>
<p><a href="e0z3m100.htm#dt2mg280">Move BCPii API calls into your application instead of in BCPii
ENF exits</a></p>
<p><a href="e0z3m100.htm#dt2mg281">Update code that invokes the IOSSPOF macro in a PSW key of
0-7</a></p>
<p><a href="e0z3m100.htm#dt2mg282">Handle changes to length of field EEPLEVENTSPECIFICINFO in
control block IXLYEEPL</a></p>
<p><a href="e0z3m100.htm#mvspgser">Change references to PGSER PROTECT/UNPROTECT</a></p>
<p><a href="e0z3m100.htm#warnund">Consider exploiting WARNUND for new IEASYS<em>xx</em> statements</a></p>
<p><a href="e0z3m100.htm#sodbcpii">Migrate from SNMP to z/OS BCPii for communication to the HMC
or SE for z/OS Capacity Provisioning support</a></p>
<p><a href="e0z3m100.htm#pgserpro">Discontinue use of PGSER to protect and unprotect the READONLY
nucleus</a></p>
<p><a href="e0z3m100.htm#dasdpfa">Define DASD storage for Predictive Failure Analysis</a></p>
<p><a href="e0z3m100.htm#oneblank">Verify that at  least one blank follows all major keyword statements
in CONSOLExx</a></p>
<p><a href="e0z3m100.htm#xtiotaba">Examine source for dynamic allocation callers that set the
S99DSABA and S99ACUCB flags</a></p>
<p><a href="e0z3m100.htm#cplibpath">Upgrade Java support for Capacity Provisioning</a></p>
<h4 id="dt2mg529">Evaluate your stand-alone dump data set allocations and your
IPCS processing of them</h4>
<p>[[[[ Technical contact: Purvi Patel/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: As your applications grow in
size and use ever greater amounts of storage, you should evaluate
whether the DASD allocated for your stand-alone dump data continues
to be adequate. <a id="idx672"></a><a id="idx673"></a></p>
<p>In z/OS V1R6, support was introduced for extended-format
sequential data sets, a form of data set that is SMS-managed and can
occupy more than 64 K tracks per volume. In z/OS V1R7, this support
was supplemented with support for large format sequential data sets
(DSNTYPE=LARGE), a form of data set that is essentially the same as
conventional sequential data sets except that more than 64 K tracks
may be spanned per volume. If your stand-alone dump data sets are
spread over more volumes than you want, both types of support can
help you gain better control over the number of volumes used for each
stand-alone dump data set.</p>
<table id="wq349" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because of changes that
have been made to stand-alone dump processing (that reorder dump records
with the intent of recording more important data early), and especially
recommended if you deploy any LPARs with significantly more main storage
than previously used.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 

</p>
<ul>
<li>Use multivolume stand-alone dump data sets. Adjust the number
of volumes and their separation to achieve tolerable stand-alone dump
capture times.</li>
<li>Use extended-format sequential data sets or large format
sequential data sets. Copy their contents to an extended-format,
compressed, striped data set using the IPCS COPYDUMP subcommand before
analysis. Use the same or a larger striping factor than you used for
your stand-alone dump data sets. Dump data sets to which stand-alone
dump can write may be neither compressed nor striped, but both attributes
are advantageous for the target of the copy operation. Starting
with z/OS V1R12, stand-alone dump data sets can be placed in
track-managed space as well as cylinder-managed space
on Extended Address Volumes (EAV).</li>
<li>Use a large CISIZE and striping for IPCS dump directories, and
use blocking, striping, and compression for the stand-alone dump data
set. Very large stand-alone dumps might require that you define your
directory with the extended addressing attribute, allowing it to hold
more than 4 GB.


<p><strong>Tips</strong>: Control interval sizes
less than 24K have been shown to be more vulnerable to fragmentation
when used as IPCS dump directories, and IPCS performance can be degraded
when such fragmentation occurs. In this background, warning message
BLS21110I will be issued and you might recreate the DDIR by using
the CLIST BLSCDDIR.
</p>
<pre class="xmp"><code>BLS21110I CISIZE(cisize) is less than 24K. It may degrade IPCS performance</code></pre></li></ul>
<p><strong>Reference information</strong>: 

</p>
<ul>
<li>For information about dump data set allocation, extended-format
sequential data sets, large format sequential data sets, and multivolume
dump data sets, see <cite>z/OS MVS Diagnosis: Tools and Service Aids</cite>.</li>
<li>For , see <cite>z/OS Problem Management</cite>.</li></ul>
<h4 id="dt2mg530">Move from the Consoles Tracking Facility to the Generic Tracker</h4><a id="idx674"></a><a id="idx675"></a><a id="idx676"></a><a id="idx677"></a>
<p> </p>
<div>
<div class="note-noindent" id="wq350">
<span class="notetitle">Note:</span> <span class="notebody">This action will be finalized in the 3rd draft review of
Migration V2R1.</span></div></div>
<p>[[[[ Contributing writer: Debra A Quick/Somers/IBM@IBMUS
]]]] [[[[ Technical contact: Ulrich Thiemann/Rochester/IBM@IBMUS]]]]</p>
<p><strong>Description</strong>: Before z/OS V2R1, the Console Tracking Facility
was used to track and flag the continued use of one specific obsolete
system function. Starting with z/OS V2R1, the Console Tracking Facility
is being replaced with a new enhanced Generic Tracker. The Console
Tracker callable service CNZTRKR is being kept for compatibility,
but it internally routes the data to the Generic Tracker infrastructure.
A corresponding Generic Tracker callable service GTZTRACK is being
introduced; it is suggested that you use it instead of CNZTRKR. Additionally,
GTZQUERY is introduced in z/OS V2R1 as a programmatic interface to
retrieve tracking data. As of z/OS V2R1, support for the Console Tracker
parmlib member, CNIDTRxx, is no longer provided. The Generic Tracker
accepts GTZPRMxx parmlib members, and a tool to convert CNIDTRxx to
the Generic Tracker GTZPRMxx is also provided.<a id="idx678"></a></p>
<table id="wq351" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if the Console
Tracker commands are not issued manually and appear in scripts or
automation. It is assumed that the retired Console Tracker commands
are typically issued manually and for diagnostic purposes only, not
in any scripts or automation tools. The callable service CNZTRKR,
compiled into executable programs continues to be supported and the
internal routing of any data passed to CNZTRKR and the Generic Tracker
will be transparent to the existing CNZTRKR caller.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  Instead of using COMMNDxx, use
the new system parameter GTZ (in IEASYSxx) to specify a GTZPRMxx member
that specifies the SETGTZ TRACKING,ON command. Instead of the DISPLAY
command, consider using utility GTZPRINT or a user-written program
with the service GTZQUERY to retrieve, store, and process current
tracking data.
</p>
<ul>
<li>Use the Generic Tracker commands manually on the console if needed.</li>
<li>Use system parameter GTZ in IEASYSxx to specify a GTZPRMxx member
that specifies SETGTZ TRACKING,ON.</li>
<li>Use GTZPRINT or a user-written program using service GTZQUERY
to retrieve, store, and process current tracking data.</li>
<li>Use GTZPRMxx parmlib members and the conversion tool
to generate GTZPRMxx from CNIDTR<span class="synph"><span class="var">xx</span></span>.</li>
<li>Convert your code to use GTZTRACK.</li></ul>
<p>Also examine the WTOR replies in the AUTOR00 parmlib member.
See <a href="e0z3m100.htm#dt2mg300">Review the list of WTORs in parmlib member AUTOR00</a>.</p>
<p><strong>Reference information</strong>: 
</p>
<ul>
<li>For details about SETGTZ, SET GTZ, DISPLAY GTZ, see <cite>z/OS MVS System Commands</cite> and
DOC APAR OA34738.</li>
<li>For details about GTZTRACK and GTZQUERY, see <cite>z/OS MVS Programming: Assembler Services
Reference ABE-HSP</cite>.</li>
<li> For details about the new Generic Tracker, see <cite>z/OS MVS Planning: Operations</cite>.</li>
<li>For details about GTZPRMxx and IEASYSxx GTZ=, see <cite>z/OS MVS Initialization and Tuning Reference</cite>.</li></ul>
<h4 id="dt2mg531">Move BCPii API calls into your application instead of in BCPii
ENF exits</h4><a id="idx679"></a><a id="idx680"></a>
<p>[[[[ Contributing writer: Rita M Beisel/Poughkeepsie/IBM
]]]] [[[[ Technical contact: Stephen Warren/Poughkeepsie/IBM ]]]]</p>
<p><strong>Description</strong>: As stated in various IBM publications, non-SRB
ENF exits need to avoid time-consuming processing. Coding an HWIEVENT
ENF exit to execute BCPii APIs may result in multiple problems, such
as delays with BCPii event notification processing when BCPii services
are simultaneously being invoked.  Starting with z/OS V1R12 and later,
BCPii enforces this restriction, and BCPii API calls made from within
a BCPii ENF exit are now rejected with return code HWI_UNSUPPORTED_ENVIRONMENT
are now rejected with return code HWI_UNSUPPORTED_ENVIRONMENT.</p>
<table id="wq352" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12 without APAR OA38117
applied to either release.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have coded a BCPii API call from
your ENF exit.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>BCPii API calls made from within a BCPii ENF
exit are now rejected with return code HWI_UNSUPPORTED_ENVIRONMENT.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If you have coded a BCPii API call from your
ENF exit, move the BCPii API call into your application and have the
BCPii ENF exit post the application when the event occurs. Your application
program may now issue the BCPii API call from the user's thread.</p>
<p>For an example of how to code a BCPii ENF exit, see the
sample ENF event exit HWIXMCX1 in SYS1.SAMPLIB.</p>
<p><strong>Reference information:</strong> For additional information, see <cite>z/OS MVS Programming: Callable Services
for High-Level Languages</cite>.</p>
<h4 id="dt2mg532">Update code that invokes the IOSSPOF macro in a PSW key of
0-7</h4><a id="idx681"></a>
<p>[[[[ Contributing writer: Rita M Beisel/Poughkeepsie/IBM
]]]] [[[[ Technical contact: Marisa N Freidhof/Poughkeepsie/IBM ]]]]</p>
<p><strong>Description</strong>: The IOSSPOF macro changed to conditionally
obtain the returned SPOFAREA in a different subpool depending on the
caller's PSW key. This may cause the caller, depending on their current
PSW key, to be required to change to a different PSW key if they want
to update the storage. In addition, certain PSW key callers can no
longer rely on the storage automatically being freed when the task
ends. The subpool number continues to be returned in the SPOFAREA_SUBPOOL
so that it can be used when the storage is freed.</p>
<p>The specific changes are:
</p>
<ul>
<li>Key 0-7 callers: The returned SPOFAREA mapped by IOSDSPOF is obtained
in subpool 252, which is key 0 storage, non-fetch-protected, and is
associated with the jobstep task.</li>
<li>Key 8-15 callers: The returned SPOFAREA mapped by IOSDSPOF continues
to be obtained in subpool 1, which is fetch-protected storage with
a key equal to the TCB key and is associated with the issuing task.</li></ul>
<p>The specific restrictions are:
</p>
<ul>
<li>Key 0-7 callers cannot rely on the SPOFAREA storage automatically
being freed when the task ends. The area must now be explicitly freed
and the caller must meet the state, key, and APF-authorization requirements
for freeing from subpool 252.</li>
<li>Key 1-7 callers must change to Key 0 in order to update the returned
SPOFAREA storage.</li>
<li>Key 8-15 callers must be in the PSW key of the TCB in order to
access the SPOFAREA storage.</li></ul>
<table id="wq353" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have code that invokes the IOSSPOF
macro in a PSW key of 0-7.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: For any program that invokes the IOSSPOF
macro in a PSW key of 0-7, ensure the following restrictions are followed:
</p>
<ul>
<li>Key 0-7 callers: Because the subpool used for the SPOFAREA has
changed from being associated with the issuing task to being associated
with the jobstep task, be sure to free the storage if your task is
not the jobstep task. In addition, make sure your storage-free invocation
meets the state, key, and APF-authorization requirements for freeing
from subpool 252.</li>
<li>Key 1-7 callers: If the program attempts to write to the returned
SPOFAREA, the program must switch to key 0 to update the area.</li></ul>
<p><strong>Reference information:</strong> For additional information, see <cite>z/OS MVS Programming: Authorized Assembler Services
Reference, Volume 2 (EDT-IXG)</cite>.</p>
<h4 id="dt2mg533">Handle changes to length of field EEPLEVENTSPECIFICINFO in
control block IXLYEEPL</h4><a id="idx682"></a>
<p>TO BE PROVIDED IN NEXT DRAFT REVIEW</p>
<p><strong>Description</strong>:</p>
<table id="wq354" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td></td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<p><strong>Reference information:</strong></p>
<h4 id="dt2mg534">Change references to PGSER PROTECT/UNPROTECT</h4><a id="idx683"></a><a id="idx684"></a><a id="idx685"></a>
<p></p>
<p>[[[[ Writer: Joshua Horton/Poughkeepsie/IBM
... Technical contact: David Hom/Poughkeepsie/IBM ]]]]</p>
<p><strong>Description</strong>: In z/OS V2R1 the MVS RSM PGSER PROTECT/UNPROTECT
macro has been changed to issue an ABEND in response to an attempt
to protect or unprotect the read-only nucleus that is backed by large
pages. In response, RSM issues abend code X&rsquo;18A&rsquo; and reason code X&rsquo;FF070411&rsquo;
(for PROTECT) or X&rsquo;FF080411&rsquo; (for UNPROTECT).</p>
<table id="wq355" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12 or z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if programs exist that use the PGSER PROTECT/UNPROTECT
macro to specify the applicable virtual storage range.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ol type="1">
<li>Search for programs that use the PGSER PROTECT/UNPROTECT macro
to specify a virtual storage range that is within the read-only nucleus
that is backed by large pages.</li>
<li>Modify all applicable programs to no longer use the PGSER PROTECT/UNPROTECT
macro to specify the applicable virtual storage range.</li>
<li>If modification to the read-only nucleus is absolutely necessary,
use the DATOFF macro.</li></ol>
<p><strong>Reference information:</strong> <cite>z/OS MVS System Codes</cite> and <cite>z/OS MVS Programming: Assembler Services
Guide</cite>.</p>
<h4 id="dt2mg535">Consider exploiting WARNUND for new IEASYS<em>xx</em> statements</h4>
<p>[[[[ Contributing writer: Marna Walle/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Peter Relson/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>:  Starting in z/OS V1R13 (and rolled
back to z/OS V1R12 and z/OS V1R11 in OA35929), you can specify the
WARNUND statement in IEASYS<span class="synph"><span class="var">xx</span></span>.  When used,
this statement indicates that warning messages <span>IEA660I
and IEA321I</span> are to be issued when undefined statements are encountered,
rather than prompting for a correct statement.  Usage of WARNUND can
be particularly useful when specifying new parmlib options in IEASYS<span class="synph"><span class="var">xx</span></span> (such
as the new IXGCNF and CATALOG system parameters which are introduced
in z/OS V1R13), and <span>allowing these new IEASYS<span class="synph"><span class="var">xx</span></span> specifications
to be shared with pre-z/OS V2R1 systems.</span><a id="idx686"></a><a id="idx687"></a></p>
<table id="wq357" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13, and rolled back to z/OS V1R12 and
z/OS V1R11 with APAR OA35929.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12 without the PTF for
APAR OA35929 applied.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td> No, but recommended to assist in sharing
IEASYS<span class="synph"><span class="var">xx</span></span> members between z/OS V2R1, and
pre-z/OS V1R13 systems, when new enhancements in z/OS V2R1 are to
be exploited.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td> Ensure the PTF for APAR OA35929 is installed
on all pre-z/OS V1R13 systems so that the WARNUND statement can be
identified and processed correctly.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>Certain restrictions are identified when using
WARNUND in IEASYS<span class="synph"><span class="var">xx</span></span>.  See reference information
below.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Install the PTF for APAR OA35929 on all pre-z/OS V1R13
systems. z/OS V1R13 has the support incorporated.</li>
<li>As you add new statements in IEASYS<span class="synph"><span class="var">xx</span></span> for
functional exploitation and you wish to share those modified IEASYS<span class="synph"><span class="var">xx</span></span> members
with pre-z/OS V2R1 systems, add <strong>WARNUND</strong> to the beginning of
IEASYS00 as that will cover updates in all IEASYS<span class="synph"><span class="var">xx</span></span> members.</li></ol>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li><cite>z/OS MVS System Messages, Vol 6 (GOS-IEA)</cite>.</li>
<li><cite>z/OS MVS Initialization and Tuning Guide</cite>.</li>
<li>Documentation in the PTFs for APAR OA35929.</li></ul>
<h4 id="dt2mg536">Migrate from SNMP to z/OS BCPii for communication to the HMC
or SE for z/OS Capacity Provisioning support</h4>
<p>[[[[ Contributing writer: Wolf-Dieter
Hahn/Germany/IBM@IBMDE ]]]] [[[[ Technical contact: Michael Groetzner/Germany/IBM@IBMDE
]]]]</p>
<p><strong>Description</strong>: z/OS V1R13 is planned to be the last
release to provide the z/OS Capacity Provisioning support that utilizes
the System z API for communication with the Support Element (SE) or
Hardware Management Console (HMC). This protocol is based on IP network
connection using SNMP. IBM recommends configuring the Capacity Provisioning
Manager for communication via the z/OS BCP Internal Interface (BCPii)
protocol. The SE and HMC support for the System z API remains, and
is not affected by this withdrawal of support. If you are currently
using SNMP for the communication, it is recommended that you now migrate
to BCPii. The migration includes enabling the communication through
BCPii for the provisioning manager user and adding a new key to the
Capacity Provisioning Manager parameter file.</p>
<table id="wq359" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use Capacity Provisioning and you
have not yet migrated to BCPii.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ul>
<li>You can use the tracking facility to help with this migration
action. In tracking facility output, look for violations that start
with CPO-W:SNMP usage <span class="synph"><span class="var">domain name</span></span>, where <span class="synph"><span class="var">domain
name</span></span> is replaced with the actual name of the affected
domain. Exploit the z/OS tracking facility on z/OS V1R12 or z/OS
V1R11 by installing the PTF for APAR OA35284. If you are
using the tracking facility and have no instances of affected domains
after starting Capacity Provisioning Manager, then this migration
action is not applicable to you.</li>
<li>Set up BCPii as described in <cite>z/OS MVS Programming: Callable Services
for High-Level Languages</cite>.</li>
<li>Define the required security profiles to allow the Capacity Provisioning
Manager user to access the hardware information.</li>
<li>Add the Topology.Protocol=INTERNAL key to the Capacity Provisioning
Manager parameter file. Using the default values, the file is the
member CPO.DOMAIN1.PARM(PARM).</li></ul>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li>For information about BCPii setup, see <cite>z/OS MVS Programming: Callable Services
for High-Level Languages</cite>.</li>
<li>For information about required security profile and how to define
the new key to the Capacity Provisioning Manager parameters, see <cite>z/OS MVS Capacity Provisioning User&amp;apos;s
Guide</cite>.</li>
<li>For information about using the tracking facility, see
"Appendix A" <cite>z/OS MVS Planning: Operations</cite>.</li></ul>
<h4 id="pgserpro">Discontinue use of PGSER to protect and unprotect the READONLY
nucleus</h4>
<p>[[[[ Contributing writer: Adrienne Becker
]]]] [[[[ Technical contact: David Hom/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Starting in z/OS V1R12, most of the READONLY
nucleus is backed by 1 MB pages. This makes protecting or unprotecting
the READONLY nucleus with the PGSER macro difficult because the macro
can only handle virtual storage pages backed by 4 KB pages. Therefore,
the PGSER macro is changed, with APAR OA33782, to no longer support
requests to protect and unprotect the READONLY nucleus if it is backed
by 1 MB pages.<a id="idx688"></a></p>
<table id="wq360" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13. z/OS V1R12 by APAR OA33782.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12 without APAR OA33782.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use the PGSER macro to protect or
unprotect the READONLY nucleus.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>Failure to discontinue use of PGSER to protect
and unprotect READONLY nucleus that is backed by 1 MB pages will result
in the ABEND18A reason codes indicated in "Steps to take," below.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Do not use PGSER to protect or unprotect
the READONLY nucleus when it is backed by 1 MB pages.  Users requiring
the modification of READONLY  nucleus should use the DATOFF macro.</p>
<p>Failure to discontinue use of PGSER to protect and unprotect READONLY
nucleus that is backed 1 MB pages will result in the following ABEND18A
reason codes: 
</p>
<ul>
<li>FF070411- The caller issued a PGSER macro with the PROTECT parameter
for virtual storage in the READONLY nucleus that is backed by 1 MB
pages. This storage area cannot be specified with the PROTECT keyword.</li>
<li>FF080411 - The caller issued a PGSER macro with the UNPROTECT
parameter for virtual storage in the READONLY nucleus that is backed
by 1 MB pages. This storage area cannot be specified with the UNPROTECT
keyword.</li></ul>
<p><strong>Reference information</strong>: For detailed information about PGSER,
see  <cite>z/OS MVS Programming: Authorized Assembler
Services Reference LLA-SDU</cite>.</p>
<h4 id="dasdpfa">Define DASD storage for Predictive Failure Analysis</h4>
<p>[[[[ Contributing writer: Jodi E Everdon/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contacts: Karla Arndt/Rochester/IBM@IBMUS ]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13, Predictive Failure Analysis
(PFA) did not document the requirement for additional DASD storage
to accommodate check output. Starting with z/OS V1R13, <cite>z/OS Problem Management</cite> contains
DASD requirements to ensure PFA has enough space to update and create
files in the z/OS UNIX file system to store check output. In addition,
because zFS no longer stores data in 1K fragments, zFS for z/OS V1R13
might need more DASD storage to store the same amount of data than
was required in previous releases. For additional information about
zFS requirements, see <a href="e0z3m100.htm#newdasd">zFS: Accommodate new DASD space requirements</a>.<a id="idx689"></a><a id="idx690"></a><a id="idx691"></a><a id="idx692"></a></p>
<table id="wq361" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use PFA.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Define additional DASD storage for PFA. The
total space for the PFA file system for each LPAR depends on the release
of z/OS you are running.   
</p>
<dl>
<dt class="bold">z/OS V1R12 (HBB7770) </dt>
<dd>200 cylinders primary; 50 cylinders secondary on a 3390 device.
</dd>
<dt class="bold">z/OS V1R13 (HBB7780) </dt>
<dd>300 cylinders primary; 50 cylinders secondary on a 3390 device.
</dd>
</dl>
<p><strong>Reference information</strong>: For additional information and storage
requirements for earlier z/OS releases, see  in <cite>z/OS Problem Management</cite>.</p>
<h4 id="oneblank">Verify that at  least one blank follows all major keyword statements
in CONSOLExx</h4><a id="idx693"></a>
<p>[[[[ Contributing writer: Service Item
#20287 ]]]] [[[[ Technical contact: Michael G Jutt/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13, you could specify INIT,
DEFAULT,  HARDCOPY and CONSOLE keyword statements without using a
blank delimiter. This can cause a problem if other keywords are misplaced
or misspelled. For example, if INTIDS(Y) is misspelled as INITIDS(Y),
the parser considers this an INIT statement. This could result in
a console not being defined correctly, or even having a system with
no consoles after initialization except the system console.</p>
<p>Starting with z/OS V1R13, if you do not have a blank character
after the four major keywords (INIT, DEFAULT, HARDCOPY, and CONSOLE), <span>you will receive a syntax error during CONSOL<span class="synph"><span class="var">xx</span></span> parmlib
processing indicated by message IEA195I or message IEA196I</span> as
shown in the example below: </p>
<pre class="xmp"><code>- IEA196I CONSOLM1 03E0: NAME REQUIRED FOR CONSOLE.
- IEA196I CONSOLM1 INIT: DUPLICATE SPECIFICATION IGNORED.
- IEA196I CONSOLM1 03E0: UNRECOGNIZED KEYWORD INITDS(Y) IGNORED.
- IEA196I CONSOLM1 03E0: UNRECOGNIZED KEYWORD INITDS(Y) IGNORED.
- IEA195I CONSOLM1 LINE1: UNRECOGNIZED STATEMENT TYPE IGNORED.
- IEA195I CONSOLM1 LINE1: UNRECOGNIZED STATEMENT TYPE IGNORED.</code></pre><p class="indatacontent"> Also,
if you do not have a blank after the major keywords INIT,  DEFAULT,
and HARDCOPY, the default values will be used.  In the case of the
major keyword, CONSOLE, you will be left with only the system console
if all of your CONSOLE statements do not end with a blank characters.</p>
<table id="wq362" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td> BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you do not have at least one blank after
any of the four major keywords INIT, DEFAULT, HARDCOPY, and CONSOLE.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Examine your CONSOL<span class="synph"><span class="var">xx</span></span> parmlib member
to verify that you have at least one blank after all of your major
keyword statements.</li>
<li>If, you do not have a blank, update your CONSOL<span class="synph"><span class="var">xx</span></span> parmlib
member by entering one or more blanks between the major keyword statements
and their associated keywords.</li></ol>
<p><strong>Reference information</strong>: For more information about the CONSOL<span class="synph"><span class="var">xx</span></span> 
parmlib member, see <cite>z/OS MVS Initialization and Tuning Reference</cite>.</p>
<h4 id="xtiotaba">Examine source for dynamic allocation callers that set the
S99DSABA and S99ACUCB flags</h4><a id="idx694"></a><a id="idx695"></a><a id="idx696"></a>
<p>[[[[ Contributing writer: James J Guilianelli/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Girija Varanasi/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: TIOTs and XTIOTs contain entries for each DD
statement allocated by either batch (JCL) or dynamic allocation. The
TIOT is a below-the-line control block that contains contiguous DD
entries, which allows for a sequential search. Because of limits on
its size and structure, a TIOT can only accommodate a specific number
of DD statements (for example, 3273 single unit DD statements for
a TIOT size of 32k.)</p>
<p>To overcome this restriction, device allocation introduced XTIOTS
or extended TIOTs above the 16M line, but the support was limited
to authorized dynamic allocation callers only because the authorized
flag S99TIOEX had to be set in order to build XTIOTs. Later, this
restriction was relaxed when unauthorized dynamic allocation callers
could request XTIOTs by setting S99ACUCB; however, the ability to
get an above-the-line data set association block (DSAB) that contains
a pointer to the TIOTs/ XTIOTs was limited to requests by authorized
callers only, because the S99DSABA flag (which can be set by authorized
or unauthorized callers) is honored only if the authorized S99TIOEX
flag also has been set.</p>
<p>In z/OS V1R12, the Basic Access Method (BAM) added support for
XTIOTs. Because it makes sense to allow unauthorized callers to get
DSABs above the line, in z/OS V1R13, device allocation added support
to build DSABs above the line when the S99DSABA bit flag is set and
either S99ACUCB or S99TIOEX is also set. Thus, unauthorized users
can fully utilize the virtual storage constraint relief (VSCR) capabilities
provided by allocation and get the benefits of both the above-the-line
DSABs and XTIOTs.</p>
<p>If any unauthorized dynamic allocation caller indicates through
S99DSABA that above-the- line DSABs are supported but encounters a
programming error in the user code when referencing above-the-line
DSABs, action is required. Before z/OS V1R13, if the dynamic allocation
callers set the S99DSABA and S99ACUCB flags, allocation built below-the-line
DSABs, scanned the below-the-line DSAB queue, and found them below
the line. For z/OS V1R13, if dynamic allocation callers request above-the-line
DSABs through S99DSABA and S99ACUCB, allocation builds above-the-line
DSABs, scans the above-the-line DSAB queue, and finds them above the
line. If the dynamic allocation callers have an existing programming
error when they attempt to reference above-the-line DSABs , they will
continue to encounter errors. If these dynamic allocation callers
need to use below-the-line DSABS , they should not set the S99DSABA.<a id="idx697"></a></p>
<table id="wq364" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have unauthorized dynamic allocation
callers that set the S99DSABA and S99ACUCB flags.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: For mission critical code, examine source
for use of S99DSABA. If found, verify that field DSQDSABA is not used
and that 4 byte (31 bit) pointers are used if the DSAB is accessed
by the program itself.</p>
<p><strong>Reference information</strong>: For details about S99DSABA and S99ACUCB,
see <cite>z/OS MVS Programming: Authorized Assembler
Services Guide</cite>.</p>
<h4 id="cplibpath">Upgrade Java support for Capacity Provisioning</h4>
<p>[[[[ Contributing writer: Wolf-Dieter
Hahn/Germany/IBM@IBMDE ]]]] [[[[ Technical contact: Michael Groetzner/Germany/IBM@IBMDE
]]]]</p>
<p><strong>Description</strong>: Starting with z/OS V1R13, the Provisioning
Manager component of Capacity Provisioning requires Java V6.0. If
the references in the ENV member of the Provisioning Manager parameters
dataset specify the location of an earlier version of Java, you must
update the LIBPATH environment variable.<a id="idx698"></a><a id="idx699"></a></p>
<table id="wq365" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use Capacity Provisioning.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>IBM 31-bit SDK for z/OS, Java Technology Edition,
V6 (5655-R31).</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ul>
<li>Install IBM 31-bit SDK for z/OS, Java 2 Technology Edition, V6
(5655-R31).</li>
<li>Change the LIBPATH variable in the ENV member of your Provisioning
Manager <span>PARM data set to point to</span> the installation
directories of your Java V6 installation. LIBPATH statement may look
like: 
<pre class="xmp"><code>LIBPATH=/usr/lib:/usr/lpp/java/J6.0/bin:usr/lpp/java/J6.0/bin/classic:
        /usr/lpp/cpo/lib</code></pre></li></ul>
<p><strong>Reference information</strong>: For information about how to adapt
the Provisioning Manager parameters, see <cite>z/OS MVS Capacity Provisioning User&amp;apos;s
Guide</cite></p>
<h3 id="dt2mg539">BCP actions to perform before the first IPL of z/OS V2R1</h3>
<p>This topic describes BCP migration actions that you can perform
after you have installed z/OS V2R1
but before the first time you IPL. These actions might require the z/OS V2R1 level of code to be installed
but do not require it to be active.</p>
<p><a href="e0z3m100.htm#aa3iplt">Create IPL text</a></p>
<p><a href="e0z3m100.htm#aa3sad">Reassemble the stand-alone dump program</a></p>
<p><a href="e0z3m100.htm#dt2mg295">Convert your existing IBM Health Checker for z/OS set-up for
automatic start-up</a></p>
<p><a href="e0z3m100.htm#dt2mg296">Plan for the increase of the maximum number of supported CPUs
to 256</a></p>
<p><a href="e0z3m100.htm#downgrade_sysdsn">Downgrade the SYSDSN ENQ control from exclusive to shared:
****** POSSIBLY REMOVED AS AN ACTION*********</a></p>
<p><a href="e0z3m100.htm#dt2mg297">Update automation that handles messages IEE302I, IEE303I, IEE1302I,
IEE1303I, and IOS566I ****** POSSIBLY REMOVED AS AN ACTION****************</a></p>
<p><a href="e0z3m100.htm#dt2mg298">Accommodate new address spaces on MAXUSER</a></p>
<p><a href="e0z3m100.htm#dt2mg556">Follow linkage conventions when you call z/OS Unicode Services</a></p>
<p><a href="e0z3m100.htm#esqa">Accommodate increase in ESQA</a></p>
<p><a href="e0z3m100.htm#nucleus">Accommodate increase in nucleus size</a></p>
<p><a href="e0z3m100.htm#dt2mg300">Review the list of WTORs in parmlib member AUTOR00</a></p>
<p><a href="e0z3m100.htm#dxcfmsg">Modify automation that references output from D XCF,SYSPLEX
console commands</a></p>
<p><a href="e0z3m100.htm#llaauto">Update LLA for automation</a></p>
<p><a href="e0z3m100.htm#pduu">Remove references to the MTFTPS utility</a></p>
<p><a href="e0z3m100.htm#conparm">Adjust CON= system parameter to accommodate default change</a></p>
<p><a href="e0z3m100.htm#hyperz196">Accommodate HiperDispatch default of YES</a></p>
<p><a href="e0z3m100.htm#commndxx">Start Runtime Diagnostics at system initialization</a></p>
<p><a href="e0z3m100.htm#operloge">Accommodate OPERLOG EMCS console name change</a></p>
<p><a href="e0z3m100.htm#oa35357">Change value for ARM restart processing</a></p>
<p><a href="e0z3m100.htm#pfaparm">Provide the <span class="synph"><span class="var">migrate</span></span> or <span class="synph"><span class="var">new</span></span> parameter
when running the PFA install script</a></p>
<p><a href="e0z3m100.htm#oa34731">Issue commands from the system console regardless of problem
determination mode</a></p>
<h4 id="dt2mg548">Create IPL text</h4>
<p><strong>Description</strong>: IPL text is bootstrap information
required for IPL (such as the location of the nucleus library).  You
must create IPL text by running ICKDSF against the system residence
volume.<a id="idx700"></a></p>
<table id="wq366" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Update and run the IPLTEXT
job to write a new copy of the IPL text. If you install z/OS with a ServerPac, an installation
dialog job is provided to perform this action. If you install z/OS with a CBPDO, instructions
to perform this action are provided in <cite>z/OS Program Directory</cite>.</p>
<p><strong>Tip</strong>:: With ICKDSF R17 APAR PM42057,
a new parameter called REMOVEIPLTXT has been added to the REFORMAT
command that allows you to remove IPL text from the volume.</p>
<div>
<div class="note-noindent" id="wq367">
<span class="notetitle">Note:</span> <span class="notebody">When the IPLTXTEXIST parameter (which was introduced
by ICKDSF R17 APAR PK16403) is specified with the REFORMAT command
using the IPLDD parameter, WTOR message ICK21836D is suppressed if
IPL text already exists.</span></div></div>
<p><strong>Reference information</strong>: For a sample IPLTEXT
job, see <cite>z/OS Program Directory</cite>. ServerPac provides a similar
job for accomplishing this task; see <cite>ServerPac: Installing Your Order</cite>.</p>
<h4 id="dt2mg549">Reassemble the stand-alone dump program</h4>
<p><strong>Description</strong>: The stand-alone dump program produces a dump
of storage that is occupied by a system that failed or a stand-alone
dump program that failed. You must reassemble the stand-alone dump
program each release. Once the stand-alone dump program is properly
created on a DASD residence volume, it resides in the SYS1.PAGEDUMP.Vvolser
data set. <a id="idx701"></a><a id="idx702"></a><a id="idx703"></a><a id="idx704"></a></p>
<table id="wq368" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to
a specific release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Reassemble the stand-alone dump program.
If you install z/OS with a ServerPac, an installation dialog job is
provided to perform this action. If you install z/OS with a CBPDO,
instructions to perform this action are provided in <cite>z/OS MVS Diagnosis: Tools and Service Aids</cite>.</p>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li><cite>ServerPac: Installing Your Order</cite></li>
<li><cite>z/OS MVS Diagnosis: Tools and Service Aids</cite></li></ul>
<h4 id="dt2mg550">Convert your existing IBM Health Checker for z/OS set-up for
automatic start-up</h4><a id="idx705"></a>
<p></p>
<p><strong>Description</strong>: Before z/OS V2R1, IBM Health Care for z/OS
users had to perform a set-up procedure and start IBM Health Checker
for z/OS manually. Now the system starts IBM Health Checker for z/OS
automatically. 
</p>
<ul>
<li>For first time user of IBM Health Checker for z/OS, follow the
steps for Optimizing IBM Health Checker for z/OS in <cite>IBM Health Checker for z/OS: User's Guide</cite>.</li>
<li>For users with existing IBM Health Checker for z/OS set-ups, use
the migration action below to convert systems to the IBM Health Checker
for z/OS automatic start-up.</li></ul>
<table id="wq369" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but strongly recommended to take advantage
of IBM Health Checker for z/OS automatic start-up for installations
with an existing IBM Health Checker for z/OS set-up..</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ol type="1">
<li>Make sure the system knows the name of your hzsproc procedure
if you renamed it from the default HZSPROC: The start-up procedure
for IBM Health Checker for z/OS is called HZSPROC, by default. If
you customized your hzsproc name, you must specify it to the system,
using the new HZSPROC system parameter in IEASYSxx.</li>
<li>Remove any existing START HZSPROC invocations that start IBM
Health Checker for z/OS and rely on the automatic start-up: Because
IBM Health Checker for z/OS now starts automatically, you must look
for instances of START HZSPROC invocations in your installation. For
example, look for START HZSPROC invocations in the COMMANDxx, parmlib
member. 

<p>After the system brings IBM Health Checker for z/OS up
automatically, the system rejects any attempt to bring up a second
instance. The system issues message HZS0101I, stating that IBM Health
Checker for z/OS is already active.</p></li>
<li>Change the way you specify the HZSPRMxx parmlib members you
want the system to use: Before z/OS V2R1, users typically specified
the HZSPRMxx parmlib members for IBM Health Checker for z/OS in the
HZSPROC procedure. Now starting with z/OS V2R1, IBM recommends that
you do the following to tell the system which members of HZSPRMxx
to use:

<ol type="a">
<li>Specify the HZSPRMxx parmlib members for your installation in
the new HZS system parameter of IEASYSxx. This provides the default
for the automatic start of IBM Health Checker for z/OS at IPL-time.</li>
<li>In your hzsproc procedure, default to or define HZSPRM='PREV'://HZSPROC
 PROC HZSPRM='PREV'                                         
  //HZSSTEP  EXEC   PGM=HZSINIT,REGION=0K,TIME=NOLIMIT,          
         //      PARM='SET PARMLIB=&amp;HZSPRM'                  
                     //*HZSPDATA DD   DSN=SYS1.&amp;SYSNAME..HZSPDATA,DISP=OLD
                    //        PEND                               
                            //        EXEC HZSPROC    HZSPRM='PREV'
specifies the following:

<ul>
<li>For manual restarts after the initial automatic start, IBM Health
Checker for z/OS will use the same HZSPRMxx parmlib members as it
did for the previous instance of IBM Health Checker for z/OS.</li>
<li>For the initial automatic start, the system will use the HZSPRMxx
suffixes listed in the HZS system parameter.</li></ul>

<p>Specifying HZSPRM='PREV' makes occasional manual restarts
(after applying service, for example) easy and consistent.</p></li></ol></li>
<li>Optionally specify an HZSPDATA data set for persistent data
in the HZSPRMxx parmlib member: Before z/OS V2R1, you could only
specify the HZSPDATA in the HZSPROC startup procedure. Now you can
define your HZSPDATA data set in either the HZSPROC startup procedure or on
the HZSPDATA parameter of the HZSPRMxx parmlib member.</li></ol>
<p><strong>Reference information:</strong> 
</p>
<ul>
<li>For system parameters HZS and HZSPROC, see IEASYSxx (system parameter
list) in <cite>z/OS MVS Initialization and Tuning Guide</cite></li>
<li>For specifying the HZSPRMxx parmlib members you want the system
to use, see "Tell the system which members of HZSPRMxx you want to
use" in <cite>IBM Health Checker for z/OS: User's Guide</cite>.</li>
<li>For details on the HZSPROC procedure, see "The HZSPROC procedure"
in <cite>IBM Health Checker for z/OS: User's Guide</cite>.</li>
<li>For specifying the HZSPDATA data set for persistent data in HZSPRMxx,
see "Create HZSPRMxx parmlib members" in <cite>IBM Health Checker for z/OS: User's Guide</cite>.</li></ul>
<h4 id="dt2mg551">Consider the new default value for the LOADxx DYNCPADD keyword
that indicates how many CPUs z/OS is prepared to dynamically add</h4>
<p>[[[[ Marna Walle]]]]</p>
<p><strong>Description</strong>: Before z/OS V2R1, through PARMLIB member LOADxx
you could enable that CPUs be added to the configuration over the
life of the IPL if the hardware supported such addition. In z/OS V2R1,
the LOADxx keyword DYNCPADD now supports a 1-4 character decimal value
nnnn that indicates how many CPUs z/OS is able to dynamically add
over the life of the IPL. The default has changed to 16.</p>
<table id="wq372" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td> Yes, if the LOADxx DYNCPADD value
is omitted (defaulted) and the default number of CPUs (16) z/OS will
be able to dynamically add over the life of the IPL is not sufficient.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>All system z hardware (z10 EC/BC and later hardware)
that supports dynamic CPU addition.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>When specifying the maximum number
of CPs that z/OS can dynamically add with LOADxx DYNCPADD <span class="synph"><span class="var">nnnn</span></span>,
this LOADxx cannot be shared with pre-V2R1 systems; that is, the <span class="synph"><span class="var">nnnn</span></span> parameter
of DYNCPADD is not recognized by pre-V2R1 systems.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>Specifying DYNCPADD nnnn or taking the DYNCPADD
 16 default allows z/OS to determine the number of CPUs that z/OS
must be prepared to be dynamically added for the life of the IPL.
 Because z/OS can know the maximum CPU id that can be dynamically
added for the life of the IPL at IPL, z/OS can obtain CPU array related
storage based on the maximum number of CPUs that can be activated
for the life of the IPL.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ol type="1">
<li>If the default limit of 16 CPUs that can be dynamically added
is not sufficient, then indicate on your LOADxx DYNCPADD the number
you desire. The maximum number of CPUs that can be added over the
life of the IPL will be capped by the minimum between the highest
CPU id hardware and the z/OS release supports.</li>
<li>Review the changed messages associated with two digit CP IDs.
Update any necessary automation or operator procedures to accommodate
the two digits. Before z/OS V2R1, there was only one digit used for
CP IDs. The messages that will now contain 2 byte CP ids are the following:
 

<ul>
<li>BLW007W MULTIPLE ACR ATTEMPTS BY CPU id</li>
<li>IEA020W AN FRR STACK POINTER FOR CPU xxxx IS DAMAGED, THE ERROR
MASK IS abcdefghijklmnopqrst</li>
<li>IEA796E ACR HAS TAKEN CPU x [LOGICALLY] OFFLINE BECAUSE <span class="synph"><span class="var">text</span></span> 

<p><span class="synph"><span class="var">text</span></span> inserts
that are updated include:  
</p>
<ul>
<li>CPU <span class="synph"><span class="var">x</span></span> CHECKSTOPPED.</li>
<li>CPU <span class="synph"><span class="var">x</span></span> REACHED ITS <span class="synph"><span class="var">vv</span></span> MACHINE-CHECK
THRESHOLD.</li>
<li>CPU <span class="synph"><span class="var">x</span></span>'S TOD CLOCK COULD NOT BE SYNCHRONIZED.</li>
<li>CPU <span class="synph"><span class="var">x</span></span>'S CLOCK COULD NOT BE SYNCHRONIZED
TO THE ETR</li></ul></li>
<li>IEE178I AUTOMATIC RECOVERY IS IN PROGRESS. NO OPERATOR ACTION
IS REQUIRED. 

<ul>
<li>[PROCESSOR (<span class="synph"><span class="var">y</span></span>) DETECTED AN EXCESSIVE
DISABLED SPIN LOOP WAITING FOR event FROM PROCESSOR (<span class="synph"><span class="var">x</span></span>)]</li>
<li>[An event OCCURRED WHEN PROCESSOR (y) TRIED TO SIGNAL PROCESSOR
(<span class="synph"><span class="var">x</span></span>)]</li></ul></li>
<li>IEE331A PROCESSOR (<span class="synph"><span class="var">y</span></span>) IS IN AN EXCESSIVE
DISABLED SPIN LOOP WAITING FOR <span class="synph"><span class="var">event</span></span>. REPLY
U OR SPIN TO CONTINUE SPIN, REPLY ABEND TO TERMINATE WORK ON PROCESSOR
(<span class="synph"><span class="var">x</span></span>) WITH RETRY REPLY TERM TO TERMINATE WORK
ON PROCESSOR (<span class="synph"><span class="var">x</span></span>) WITHOUT RETRY OR STOP PROCESSOR
(<span class="synph"><span class="var">x</span></span>) AND REPLY ACR</li>
<li>ISN011I CPU nnnn HAS BEEN ADDED</li></ul></li></ol>
<p><strong>Reference information</strong>: <cite>z/OS MVS Initialization and Tuning Reference</cite>.</p>
<h4 id="dt2mg552">Plan for the increase of the maximum number of supported CPUs
to 256</h4><a id="idx706"></a>
<p><strong>Description</strong>: In z/OS V2R1, z/OS CPU infrastructure will
support up to a maximum of 256 CPUs (CPU ids 0-255). Earlier releases
of z/OS support up to 100 CPUs (CPU ids 0-99). Components or products
allocating storage for CPU related arrays or bitmasks might require
changes to support the V2R1 CPU infrastructure.</p>
<p>Allocating CPU related arrays or bitmasks on a per CPU basis is
done using one of the following: 
</p>
<ul>
<li>Run-time fields in the z/OS CVT (mapped by CVT) and ECVT (mapped
by IHAECVT) control blocks representing the maximum CPU id a z/OS
image can use for the life of the IPL. Products using run time fields
will not require changes to support the V2R1 CPU infrastructure.</li>
<li>Compile-time or assemble-time constants in the z/OS ECVT control
block or within the product itself representing the maximum CPU id
the z/OS CPU infrastructure supports. Products using compile-time
or assemble-time constants will need to recompile at a minimum and
may require code changes to support the V2R1 CPU infrastructure.</li></ul><p class="indatacontent">All products running on z/OS V2R1 must prepare to support all
CPUs supported by the z/OS V2R1 CPU infrastructure (up to 256 CPUs
with CPU ids 0-255). Products that support the z/OS V2R1 CPU infrastructure
will be able to run on earlier z/OS releases whose CPU infrastructure
supports a fewer number of CPUs.</p>
<table id="wq374" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
the first IPL of z/OS V2R1</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, for for programs using local constants
or the z/OS constants for the number of CPUs the z/OS CPU infrastructure
supports at the current or a specific level of z/OS</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>Programs that do not support up to the maximum
number of CPUs the z/OS infrastructure supports might not be able
to work with all CPUs on the z/OS image. The system impacts are program
dependent.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ul>
<li>Scan your code for all of the constants in the ECVT control block
below that have a prefix of ECVT_max_* or ECVT_zOSR11_*. These fields
are all related to the maximum CPU id the current or a specific z/OS
release supports.</li>
<li>Scan your code for compile-time or assemble-time constants in
your product for constants related to the maximum CPU id that the
current or a specific z/OS release supports. Also scan your product
for constants related to the maximum number of CPUs the current or
a specific z/OS release supports.</li></ul>
<p>If you use ECVT constants with a prefix of ECVT_max_* or ECVT_zOSR11_*
, the product will require the following changes:
</p>
<ul>
<li>If the ECVT_zOSR11_highestCPUID or ECVT_max_highestCPUID constants
are in use:, consider upgrading your code to use the run-time field
CVTMAXMP (for allocating CPU related arrays) or ECVT_Installed_CPU_HWM
(for traversing CPU related arrays). &bull;</li>
<li>If ECVT compile-time or assemble-time constants with a prefix
of ECVT_max_* are in use, recompile/reassemble all appropriate parts
with the new z/OS V2R1 IHAECVT macro.</li>
<li>If ECVT compile-time or assemble-time constants with a prefix
of ECVT_zOSR11_* are in use, consider converting constants with a
prefix of ECVT_zOSR11_* to the ECVT_max_* analog. Otherwise change
ECVT_zOSR11_* to the new ECVT_zOSV2R1 analog.</li></ul><p class="indatacontent"> If your code has its own local declares for compile-time or
assembler-time constants, update your code to use the z/OS run-time
fields or the z/OS compile-time or assemble-time constants. To do
this, see ICN Request Greater Than 64 CPUs 10-22-07????? and do the
following:
</p>
<ol type="1">
<li>Allocate CPU bit masks at compile-time or assemble-time using
ECVT_max_CPUMaskSizeInBits or ECVT_max_CPUMaskSizeInBytes.</li>
<li>Convert to using run-time fields like CVTMAXMP to allocate your
local CPU related arrays. If using run-time fields is undesirable,
allocate CPU arrays using the compile-time or assemble time constants
ECVT_max_* or ECVT_zOSV2R1_* fields</li></ol>
<p><strong>Reference information:</strong> 
NEED A REFERENCE.</p>
<h4 id="dt2mg553">Downgrade the SYSDSN ENQ control from exclusive to shared:
****** POSSIBLY REMOVED AS AN ACTION*********</h4><a id="idx707"></a><a id="idx708"></a><a id="idx709"></a><a id="idx710"></a><a id="idx711"></a><a id="idx712"></a>
<p>[[[[ Contributing writer: Debra A Quick/Somers/IBM@IBMUS
]]]] [[[[ Technical contact: Brian Keuling/Poughkeepsie/IBM]]]]</p>
<p> eReview discussion from first review suggests removing
this action.</p>
<p></p>
<div>
<div class="note-noindent" id="wq376">
<span class="notetitle">Note:</span> <span class="notebody">This action will be finalized in the 3rd draft review of
Migration V2R1.</span></div></div>
<p><strong>Description</strong>: Before z/OS V2R1, the SYSDSN ENQ was exclusive.
Starting with z/OS V2R1, the SYSDSN ENQ control can be changed from
exclusive to shared. This change can affect the function by allowing
better parallelism of batch execution when multiple jobs need to share
a data set resource. The downgrading of control level has potential
to speed up batch processing; however it can expose problems in user
JCL.<a id="idx713"></a></p>
<table id="wq377" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Optional, if the user decides to downgrade the
SYSDSN ENQ control.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Determine if the JCL can accommodate having
its SYSDSN ENQ downgraded. If the data set is being modified after
its last exclusive usage requesting step, then the new function will
be problematic for that particular job. Therefore, it should not be
requesting through the JES jobclass attribute/JCL keyword to enable
the new function.</p>
<p><strong>Reference information</strong>: For details about downgrading the
SYSDSN ENQ control from exclusive to shared, see .</p>
<h4 id="dt2mg554">Update automation that handles messages IEE302I, IEE303I, IEE1302I,
IEE1303I, and IOS566I ****** POSSIBLY REMOVED AS AN ACTION****************</h4><a id="idx714"></a>
<p>[[[[ Contributing writer: Rita M Beisel/Poughkeepsie/IBM
]]]] [[[[ Technical contact: Ilene Goldman/Poughkeepsie/IBM ]]]]</p>
<p><strong>Description</strong>: Starting in z/OS V2R1, the following messages
have changed message text:
</p>
<ul>
<li>Messages IEE302I, IEE303I, IEE1302I, and IEE1303I are changed
from including ESCM in the message text to including CONFIG MANAGER
in the message text.</li>
<li>Message IOS566I is changed from including SYSTEM AUTOMATION in
the message text to including CONFIG MANAGER in the message text.</li></ul>
<p>If you use automation programs to handle messages, or you have
operator or other procedures that deal with messages, you should update
the programs or procedures appropriately.</p>
<table id="wq378" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use automation programs or other
procedures to handle messages IEE302I, IEE303I, IEE1302I, IEE1303I,
and IOS566I.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Modify automated actions for IEE302I, IEE303I,
IEE1302I, IEE1303I, and IOS566I so they now work with the updated
message text.</p>
<p><strong>Reference information:</strong> For details about messages IEE302I,
IEE303I, IEE1302I, and IEE1303I, see <cite>z/OS MVS
System Messages, Volume 7 (IEB-IEE)</cite>. For details about messages
IOS566I, see <cite>z/OS MVS System Messages, Volume
9 (IGF-IWM)</cite>.</p>
<h4 id="dt2mg555">Accommodate new address spaces on MAXUSER</h4><a id="idx715"></a><a id="idx716"></a><a id="idx717"></a>
<p>[[[[ Contributing writer: Rita M Beisel/Poughkeepsie/IBM
]]]] [[[[ Technical contact: Ken Yee/Poughkeepsie/IBM and Dale Riedy/Poughkeepsie/IBM]]]]</p>
<p><strong>Description</strong>: The MAXUSER value in parmlib member IEASYS<em>xx</em> specifies
a value that the system uses to limit the number of jobs and started
tasks that can run concurrently during a given IPL. Increase your
MAXUSER value to take new address spaces into account.</p>
<p>There are two new address spaces in z/OS V2R1 called PCIE (PCI
Express) and FPGHWAM (Hardware Accelerator Manager). They provide
the infrastructure for PCI Express I/O and hardware accelerator activities.</p>
<p>These address spaces are started automatically during z/OS initialization,
if the appropriate z/OS PCIE facilities hardware is installed. They
are persistent address spaces.</p>
<p>If the PCIE address space is successfully initialized, message
IQP002I PCIE INITIALIZATION COMPLETE is displayed.</p>
<p>If the required hardware is not installed, message IQP031I REQUESTED
SERVICE IS UNSUPPORTED BY HARDWARE is written to the hardcopy log.</p>
<table id="wq379" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to ensure that your MAXUSER
value in parmlib member IEASYSxx is adequate.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If necessary, increase your MAXUSER value
in parmlib member IEASYS<em>xx</em> to take the new address
spaces into account. One way to find out how many address spaces you
use is to issue the DISPLAY A,L command and total the address spaces
in the IEE114I and IEE115I messages on the old and new systems.</p>
<p>Notes:
</p>
<ol type="1">
<li>A modest overspecification of MAXUSER should not hurt system performance.</li>
<li>The number of total address spaces is the sum of M/S, TS USERS,
SYSAS, and INITS.</li>
<li>If you change your MAXUSER value, you must re-IPL to make the
change effective.</li></ol>
<p><strong>Reference information:</strong> For information about the MAXUSER
parameter, including its interaction with the RSVSTRT and RSVNONR
parameters and factors that contribute to the number of active address
spaces, see <cite>z/OS MVS Initialization and Tuning
Reference (IGF-IWM)</cite>.</p>
<p>For information about the hardware accelerator-related messages,
see <cite>z/OS MVS System Messages, Volume 5 (EDG-GFS)</cite>.</p>
<p>For information about the PCIE messages, see <cite>z/OS
MVS System Messages, Volume 9 (IGF-IWM)</cite>.</p>
<h4 id="dt2mg556">Follow linkage conventions when you call z/OS Unicode Services</h4><a id="idx718"></a><a id="idx719"></a>
<p>[[[[ Contributing writer: Rita M Beisel/Poughkeepsie/IBM
]]]] [[[[ Technical contact: Pat Glenski/Rochester/IBM ]]]]</p>
<p><strong>Description</strong>: Starting in z/OS V1R13, z/OS Unicode Services
enforces the linkage conventions documented in <cite>z/OS
Unicode Services User's Guide and Reference</cite>. The z/OS Unicode
Services interfaces follow the MVS linkage conventions described in
'Linkage Conventions' in <cite>z/OS MVS Programming:
Assembler Services Guide</cite>.</p>
<table id="wq381" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are using z/OS Unicode Services.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Verify that when you call the z/OS Unicode
Services interfaces, you follow the linkage conventions. Specific
details about the conventions that are enforced are included in the
documentation of each z/OS Unicode Services interface. In general,
the linkage conventions are:
</p>
<ul>
<li>GPR 1 - Caller must set to the address of the parameter area.</li>
<li>GPR 13 - Caller must set to the address of a save area.</li>
<li>GPR 14 - Caller must set to the return address.</li>
<li>GPR 15 - Caller must set to the entry address. The stub routines
do this automatically.</li></ul>
<p><strong>Reference information:</strong> For more information about these
linkage conventions, see the section on 'Linkage conventions' in<cite>z/OS Unicode Services User's Guide and Reference</cite>.
For more information about the MVS linkage conventions, see <cite>z/OS MVS Programming: Assembler Services Guide</cite>.</p>
<h4 id="dt2mg557">Accommodate increase in ESQA</h4>
<p>[[[[ Contributing writer: &lt;Example,
Jodi E Everdon/Poughkeepsie/IBM@IBMUS &gt; ]]]] [[[[ Technical contact: &lt;Example:
Karla Arndt/Rochester/IBM@IBMUS &gt; ]]]]</p>
<p><strong>Description</strong>: With the introduction of the z/OS V1R13 RSM Enablement Offering
Web deliverable, there is an increase of 24K (6 pages) in ESQA per
CPU per LPAR. This increase in ESQA per CPU includes general purpose
CPs, zIIPs, and zAAPs regardless of the status (online, offline, configured,
stand-by, and so forth) of the hardware. Because of this increase,
the available private storage may affect application execution on
your system.</p>
<table id="wq382" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx720"></a><a id="idx721"></a><a id="idx722"></a><strong>Element or
feature</strong>:</td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13
RSM Enablement Offering Web deliverable.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13
without the z/OS V1R13 RSM
Enablement Offering Web deliverable or from z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the increase in ESQA will affect the
private storage available to applications on your system.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>The migration action is relevant on all servers.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>Failure to have sufficient private storage available
might result in errors that affect the running of your applications.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>VSM_CSA_CHANGE. You can use this health check
to identify changes in the size of CSA or private (including the extended
areas) since the last IPL.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Review your current available private storage
usage above the 16 MB line using reports from RMF or an equivalent product. Ensure that an
ESQA increase of 24K per CPU used on the LPAR will not adversely affect
your system. Adjust values  accordingly.</p>
<p><strong>Reference information</strong>: See <a href="e0z3m100.htm#at3limi">Verify that virtual storage limits are set properly</a></p>
<p>Also see <cite>z/OS MVS Initialization and Tuning Guide</cite> and<cite>z/OS MVS Initialization and Tuning Reference</cite>.</p>
<h4 id="dt2mg558">Accommodate increase in nucleus size</h4>
<p>[[[[ Contributing writer: &lt;Example,
Jim Guilinrelli/Poughkeepsie/IBM@IBMUS &gt; ]]]] [[[[ Technical contact: &lt;Marna
Walle/Poughkeepsie/IBM@IBMUS &gt; ]]]]</p>
<p><strong>Description</strong>: With the introduction of the z/OS V1R13 RSM Enablement Offering Web deliverable,
the nucleus will increase in size by approximately 380K above the
16MB line. Because of this increase, the available private storage
might affect the way your applications run on your system.<a id="idx723"></a></p>
<table id="wq383" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13
RSM Enablement Offering Web deliverable.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13
without the z/OS V1R13 RSM
Enablement Offering Web deliverable or from z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the increase in nucleus size will affect
the private storage available to applications on your system above
the 16MB line.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None. The migration action is relevant on all
servers.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>Failure to have sufficient private storage available
might result in errors that affect the running of your applications.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td> VSM_CSA_CHANGE. You can use this health check
to identify changes in the size of CSA or private (including the extended
areas) since the last IPL.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Review your current available private storage
usage above the 16MB line using reports from RMF or an equivalent product. Ensure that an
increase of 380K for the nucleus above the 16 MB line will not adversely
affect your system. Adjust values accordingly.</p>
<p><strong>Reference information</strong>: See <a href="e0z3m100.htm#at3limi">Verify that virtual storage limits are set properly</a></p>
<p>Also see <cite>z/OS MVS Initialization and Tuning Guide</cite> and <cite>z/OS MVS Initialization and Tuning Reference</cite>.</p>
<h4 id="dt2mg559">Review the list of WTORs in parmlib member AUTOR00</h4><a id="idx724"></a>
<p>[[[[ Contributing writer: Jing Die Huang/China/IBM@IBMCN
]]]] [[[[ Technical contact: Richard Bibolet/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: In z/OS V1R12, the DDDEF"d
PARMLIB provides an AUTOR00 member. This member should be found in
your parmlib concatenation during IPL and will result in auto-reply
processing being activated. If the WTORs listed in AUTOR00 are automated
by your existing automation product, ensure that the replies in AUTOR00
are appropriate.</p>
<table id="wq384" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td align="left">BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td align="left">z/OS V1R12. General migration
action.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td align="left">z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td align="left">Before the first IPL of z/OS
V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td align="left">Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td align="left">None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td align="left">None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td align="left">None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td align="left">None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td align="left">None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td align="left">None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Examine the WTOR replies in the AUTOR00 parmlib
member. If the replies or delay duration are not desirable, you can
create a new AUTORxx parmlib member and make corresponding changes.
Also compare the replies to what your automation product would reply
to these WTORs. Make sure that the AUTOR00 replies are in accordance
with the replies from your automation product. IBM does not recommend
making updates to AUTOR00, because updates to AUTOR00 might be made
by the service stream or in new z/OS releases.</p>
<div>
<div class="note-noindent" id="wq385">
<span class="notetitle">Note:</span> <span class="notebody">
<ul>
<li>If you have created an AUTORxx parmlib member, update the IEASYSyy
parmlib member that you use for IPL. Add the following statement to
the IEASYSyy member:  
<pre class="xmp"><code>AUTOR=(xx,00)</code></pre>Here xx
corresponds to the AUTORxx parmlib member that you created.  The IEASYSyy
members specifying AUTOR cannot be shared with prior z/OS releases.
If you only need the default AUTOR00 settings, you can omit specifying
AUTOR= in IEASYSyy, and other z/OS levels can continue to use IEASYSyy.
Even if AUTOR= is not specified in IEASYSyy, AUTOR00 is used if it
exists. If you have automation already in place for a WTOR and that
WTOR now appears in AUTOR, the AUTOR version still can be used. Review
the WTORs in AUTOR and your automation; either remove the WTOR from
AUTOR or from your automation.</li>
<li>If you don't want to activate auto-reply processing, specify AUTOR=OFF
in the parmlib member IEASYSxx or in response to message IEA101A SPECIFY
SYSTEM PARAMETERS. It is not recommended that you remove AUTOR00 from
parmlib, because service or new releases might reinstall AUTOR00.
If there is no AUTOR00 member in parmlib, auto-reply is not activated
and the following messages are produced:
<pre class="xmp"><code>CNZ2600I AUTO-REPLY POLICY ATTEMPTING TO USE AUTOR=00.          
IEA301I AUTOR00 NOT FOUND IN PARMLIB                               
CNZ2601I AUTO-REPLY POLICY NOT ACTIVATED. 
NO ENTRIES SPECIFIED</code></pre></li>
<li>The IEASYSyy members specifying AUTOR=OFF cannot
be shared with earlier z/OS releases.</li></ul></span></div></div>
<p><strong>Reference information:</strong> For more information about the AUTORxx
and IEASYSyy parmlib members, see <cite>z/OS MVS Initialization and Tuning Reference</cite>.</p>
<h4 id="dxcfmsg">Modify automation that references output from D XCF,SYSPLEX
console commands</h4><a id="idx725"></a><a id="idx726"></a>
<p>[[[[ Contributing writer: James J Guilianelli/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Scott Schiffer/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13, when the following <span class="synph"><span class="kwd">D
XCF</span></span> console commands were issued, the resulting messages
contained output information from the command depending on the options
specified:  
</p>
<ul>
<li><span class="synph"><span class="kwd">D XCF</span></span> 
<pre class="xmp"><code>IXC334I   hh.mm.ss  DISPLAY XCF SYSPLEX <span class="synph"><span class="var">sysplex-name</span></span>: <span class="synph"><span class="var">sysname sysname</span></span>
     <span class="synph"><span class="var">sysname</span></span> <span class="synph"><span class="var">sysname</span></span></code></pre></li>
<li><span class="synph"><span class="kwd">D XCF,SYSPLEX</span></span> 
<pre class="xmp"><code>IXC334I   hh.mm.ss  DISPLAY XCF SYSPLEX <span class="synph"><span class="var">sysplex-name</span></span>: <span class="synph"><span class="var">sysname sysname</span></span>
     <span class="synph"><span class="var">sysname</span></span> <span class="synph"><span class="var">sysname</span></span></code></pre></li>
<li><span class="synph"><span class="kwd">D XCF SYSPLEX,ALL | </span><span class="var">system name </span></span> 
<pre class="xmp"><code>IXC335I   hh.mm.ss  DISPLAY XCF <span class="synph"><span class="var">text</span></span></code></pre></li></ul>
<p>Starting with z/OS V1R13, the output message for a <span class="synph"><span class="kwd">D
XCF,SYSPLEX</span></span> command is changed to IXC336I, which provides
more basic information about a system. In addition, a new output message,
IXC337I, is issued for a <span class="synph"><span class="kwd">D XCF,SYSPLEX</span></span> command
when a system name or ALL is specified. Detailed sysplex and system
information was added and reformatted in the new message. These changes
can affect your message automation programs. 
</p>
<ul>
<li><span class="synph"><span class="kwd">D XCF</span></span> 
<pre class="xmp"><code>IXC334I   hh.mm.ss  DISPLAY XCF SYSPLEX <span class="synph"><span class="var">sysplex-name</span></span>: <span class="synph"><span class="var">sysname sysname</span></span>
     <span class="synph"><span class="var">sysname</span></span> <span class="synph"><span class="var">sysname</span></span></code></pre></li>
<li><span class="synph"><span class="kwd">D XCF,SYSPLEX</span></span> 
<pre class="xmp"><code>IXC336I hh.mm.ss DISPLAY XCF text
SYSTEM  TYPE  SERIAL  LPAR  STATUS TIME  SYSTEM STATUS
<span class="synph"><span class="var">sysname</span></span> <span class="synph"><span class="var">type</span></span>  <span class="synph"><span class="var">serial</span></span>  <span class="synph"><span class="var">lpar</span></span>    <span class="synph"><span class="var">m/dd/yyyy</span></span>         <span class="synph"><span class="var">status</span></span>

SYSTEM STATUS DETECTION PARTITIONING PROTOCOL CONNECTION EXCEPTIONS: <span class="synph"><span class="var">local_limit</span></span> 
SYSTEM DIAG INFO: <span class="synph"><span class="var">cpiiservice faileddatetime retcode</span></span>
SYSTEM ABEND CODE: <span class="synph"><span class="var">abendcode</span></span> ABEND REASON CODE: <span class="synph"><span class="var">abendrsncode</span></span>
TIME OF FAILURE: <span class="synph"><span class="var">abenddatetime</span></span></code></pre></li>
<li><span class="synph"><span class="kwd">D XCF,SYSPLEX,ALL</span></span> | <span class="synph"><span class="var">system
name</span></span> 
<pre class="xmp"><code>IXC337I hh.mm.ss DISPLAY XCF
SYSPLEX <span class="synph"><span class="var">sysplex-name</span></span> MODE: <span class="synph"><span class="var">plex_mode</span></span>
SYSTEM <span class="synph"><span class="var">system-name</span></span> STATUS: <span class="synph"><span class="var">system-status
                                         system-status</span></span>
TIMING: <span class="synph"><span class="var">system-timing</span></span>
STATUS TIME: <span class="synph"><span class="var">activetime</span></span>
JOIN TIME: <span class="synph"><span class="var">activetime</span></span>
SYSTEM NUMBER: <span class="synph"><span class="var">system-number</span></span></code></pre></li></ul>
<table id="wq386" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use automation programs or other
procedures to handle message IXC335I.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Modify automation that references output
from <span class="synph"><span class="kwd">D XCF,SYSPLEX</span></span>, <span class="synph"><span class="kwd">D XCF,SYSPLEX,ALL</span></span>,
and <span class="synph"><span class="kwd">D XCF,SYSPLEX,</span></span><span class="synph"><span class="var">systemname</span></span> commands.
Message IXC337I replaces IXC335I. IXC335I is no longer issued.</p>
<p><strong>Reference information</strong>: For details about the message output
for IXC334I, IXC336I, and IXC337I, see <cite>z/OS MVS System Messages, Vol 10 (IXC-IZP)</cite>.</p>
<h4 id="llaauto">Update LLA for automation</h4>
<p>[[[[ Contributing writer: Jodi E Everdon/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Peter Relson/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13, if you started
library lookaside (LLA) using a CSVLLA<span class="synph"><span class="var">xx</span></span> parmlib
member, and then stopped and restarted LLA without using a parmlib
member, LLA honored the "no parmlib member" state and managed only
the data sets in the LNKLST concatenation. Beginning with z/OS V1R13,
the same scenario results in using the CSVLLA<span class="synph"><span class="var">xx</span></span> parmlib
member with which LLA previously started. To get back to the "no parmlib
member" state, you must specify <span class="synph"><span class="kwd">LLA=NONE</span></span> when
starting LLA.</p>
<div>
<div class="note-noindent" id="wq387">
<span class="notetitle">Note:</span> <span class="notebody">If F LLA,UPDATE=xx command is done in between, the
update is not honored by the restarted LLA, which is started without
specifying LLA=xx.</span></div></div>
<table id="wq388" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx727"></a><a id="idx728"></a><a id="idx729"></a><a id="idx730"></a><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have automation or operator procedures
that restart LLA and you want LLA to restart with no parmlib member
even when you previously started LLA with a parmlib member.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If you have automation in place to restart
LLA and you want automation to restart without a parmlib member even
when you had started LLA with a parmlib member, you must change it
to use the <samp class="xph">LLA=NONE</samp> parameter.</p>
<p><strong>Reference information</strong>: See the topic on  in <cite>z/OS MVS Initialization and Tuning Reference</cite></p>
<h4 id="pduu">Remove references to the MTFTPS utility</h4>
<p>[[[[Contributing writer: Jodi E Everdon/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Purvi Patel/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13, you might have used the
problem documentation upload utility (PDUU), packaged as MTFTPS, to
send large volumes of problem documentation, such as stand-alone dumps,
to IBM support. Beginning with z/OS V1R13, the z/OS problem documentation
upload utility (PDUU) is a standard part of the base operating system
with entry point name AMAPDUPL. <a id="idx731"></a><a id="idx732"></a></p>
<table id="wq389" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if you previously used the
stand-alone version of PDUU (MTFTPS).</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: To avoid possible conflicts, remove the stand-alone
version of the PDUU utility and begin using the supported version:</p>
<ol type="1">
<li>Remove any prior version of MTFTPS from your system. The PDUU
utility name is AMAPDUPL <span>(in SYS1.MIGLIB)</span>, although
MTFTPS is shipped as an alias entry point to AMAPDUPL</li>
<li>Begin using the PDUU as the primary utility for sending large
volumes of product documentation to IBM Support.</li></ol>
<p><strong>Reference information</strong>: For complete details, including JCL
statements and examples, see the topic on  in <cite>z/OS MVS Diagnosis: Tools and Service Aids</cite>.</p>
<h4 id="conparm">Adjust CON= system parameter to accommodate default change</h4>
<p>[[[[ Contributing writer: Rita M Beisel/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Peter Fatzinger/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13, the default console
operating mode was SHARED. Beginning with z/OS V1R13, the default
console operating mode is changing from SHARED mode to DISTRIBUTED
mode. The release of z/OS following z/OS V2.1 is planned to be the
last release in which the consoles component will support shared mode.
IBM recommends that you migrate to distributed mode, which was introduced
in z/OS V1.10.</p>
<table id="wq391" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx733"></a><a id="idx734"></a><a id="idx735"></a><a id="idx736"></a><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if there is no specification on the CON=
system parameter and SHARED mode is required.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>Impacts could be experienced falling back to
shared, but only after taking advantage of some of the functionality
offered in distributed. For more information, see "Operation modes
of console support" in <cite>z/OS MVS Planning: Operations</cite>.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>Use check ZOSMIGV1R13_CNZ_CONS_OPER_MODE<span>, available with APAR OA32930,</span> to determine if your
installation has explicitly identified your console service operating
mode.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Examine the system parameters used to IPL
the system or sysplex. The initial mode is specified on the CON= system
parameter. <span>Use the <span class="synph"><span class="kwd">D OPDATA,MODE</span></span> to
find the current mode, which is displayed in message CNZ9006I.</span> 
</p>
<ul>
<li>If DISTRIBUTED is specified, no action is required.</li>
<li>If SHARED is specified, an action is not currently required, but
DISTRIBUTED mode will become a required action in the future.</li>
<li>If there is no specification on the CON= system parameter, DISTRIBUTED
mode is now the default.</li>
<li>If there is no specification on the CON= system parameter and
SHARED mode is required, you have to explicitly request the SHARED
mode on the CON= system parameter. This allows the system or systems
to continue functioning in the same manner as they do today. <span>Use
the SETCON MODE=SHARED command to request SHARED mode.</span></li></ul><p class="indatacontent"> <span><strong>Tip</strong>: When you activate the OPERCMDS FACILITY
class, you must have the CONTROL access authority to the profile when
issuing the SETCON MODE command.</span></p>
<p><strong>Reference information</strong>: For more information, see: 
</p>
<ul>
<li>DOC APAR OA34738.</li>
<li> <cite>z/OS MVS Initialization and Tuning Reference</cite>.</li>
<li><cite>z/OS MVS Planning: Operations</cite>.</li></ul>
<h4 id="hyperz196">Accommodate HiperDispatch default of YES</h4>
<p>[[[[ Contributing writer: Andrea Franck/Germany/IBM@IBMDE
]]]] [[[[ Technical contact: Guenter Vater/Germany/IBM@IBMDE ]]]]</p>
<p><strong>Description</strong>: Beginning with z/OS V1R13 when running
on a z196, z114, or later server, the IEAOPT<span class="synph"><span class="var">xx</span></span> keyword
HIPERDISPATCH will default to YES. If HIPERDISPATCH=NO is specified,
the specification will be honored as it was on previous z/OS releases.<a id="idx737"></a><a id="idx738"></a></p>
<table id="wq392" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but it is recommended. You should be aware
of changes in how system resources are being managed.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>IBM zEnterprise z196, z114, or later server.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>Use IBM z/OS Health Checker check SUP_HiperDispatch
to determine whether the expected HiperDispatch check parameter state,
HIPERDISPATCH YES | NO, matches the actual HiperDispatch state of
the system. 

<p>Beginning with z196 and z114 machines on z/OS V1R13,
anyone making the SUP_HiperDispatch health check succeed by specifying
a parameter of HIPERDISPATCH(NO) for a z/OS image running in HIPERDISPATCH=NO
will need to specify the machine types(s) where HiperDispatch(NO)
is acceptable using the MachTypes parameter; for example, MachTypes(2817).</p> 

<p>If
the HiperDispatch(NO) parameter is provided to the SUP_HiperDispatch
health check, the machine is a z196 or a z114, and the current machine
type does not appear in the MachTypes list, the check will expect
a HiperDispatch state of HIPERDISPATCH(YES).</p></td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<p>Examine the IEAOPT<span class="synph"><span class="var">xx</span></span> member(s)
used for each image that will be IPLed on an IBM zEnterprise server.
Then find the HIPERDISPATCH keyword and take one of the following
actions. (You can issue the RMF Monitor-II OPT command to get the
current IEAOPTxx parmlib setting.) 
</p>
<ul>
<li>For HiperDispatch=YES, no action is required.</li>
<li>When the HiperDispatch keyword is omitted, note that the image
will take the default of HiperDispatch=YES and IPL with HiperDispatch
enabled. Decide if you wish to accept that HiperDispatch will be enabled
by default by reviewing the subsequent steps, and the "HiperDispatch=YES
considerations" section.</li>
<li>For HiperDispatch=NO, investigate why that image was running in
HiperDispatch=NO and choose one of the following: 

<ul>
<li>Define a plan to migrate that image to HiperDispatch=YES. See
the "HiperDispatch=YES considerations" section for further information.</li>
<li>Continue to run the image with HiperDispatch=NO (IBM
does not recommend this option for LPARs where the LPAR weight guarantees
a share of two or more physical processors without a compelling reason
for running HiperDispatch=NO). 

<p>To get the SUP_HiperDispatch health
check to succeed, add the machine type to the MachTypes parameter
and verify that the HIPERDISPATCH parameter is NO.</p></li></ul></li></ul>
<p><strong>HiperDispatch=YES considerations</strong>: 
</p>
<ul>
<li>Before enabling HiperDispatch review the WLM policy and make appropriate
changes as needed that are described in the &quot;WLM Policy Considerations&quot;
in the &quot;Planning Considerations For HiperDispatch Mode&quot; white paper
at http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101229.</li>
<li>Verify that the LPAR profiles of the partitions in which the system
may be IPLed allow for "Global Performance Data Control". See the <em>Processor
Resource/Systems Manager Planning Guide</em> for a description of this
capability. If this capability is not allowed, WLM will be unable
to understand capacity that is  used by other LPARs and will use all
logical processors. Using all logical processors will result in suboptimal
use of cache, reducing the capacity of the partition when more logical
processors are defined compared to the share of the partition. This
can also result in the "short CP" effect where a logical processor
may have a unit of work dispatched while removed from a physical processor
for significant intervals. This can lead to response time problems.</li></ul>
<p><strong>Reference information</strong>: 
</p>
<ul>
<li><em>"Planning Considerations for HiperDispatch Mode" white paper</em> 
at IBM Techdocs <a href="http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101229">http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101229</a>.</li>
<li><em>Processor Resource/Systems Manager Planning Guide</em></li>
<li><cite>z/OS MVS Initialization and Tuning Reference</cite></li>
<li><cite>z/OS MVS Planning: Workload Management</cite></li>
<li><cite>IBM Health Checker for z/OS: User's Guide</cite></li></ul>
<h4 id="commndxx">Start Runtime Diagnostics at system initialization</h4><a id="idx739"></a><a id="idx740"></a><a id="idx741"></a><a id="idx742"></a>
<p>[[[[ Contributing writer: Jodi E Everdon/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Donald Durand/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13, Runtime Diagnostics ran
as a as a started task under the master subsystem and had to be started
each time you wanted an analysis. It was started, did its analysis,
then ended. Beginning with z/OS V1R13, you can start Runtime Diagnostics
to run as an address space under the master subsystem. After you start
the Runtime Diagnostics address space (HZR), it remains running until
stopped using the STOP command. Use the <samp class="xph">MODIFY HZR,ANALYZE</samp> command
to generate a Runtime Diagnostics analysis and report.<a id="idx743"></a><a id="idx744"></a></p>
<table id="wq393" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to use Runtime Diagnostics.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td> None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: To start the Runtime Diagnostics address
space (HZR):</p>
<ol type="1">
<li>Ensure the hzrproc (HZR) points to PGM=HZRINIT, not PGM=HZRIMAIN
as in z/OS V1R12. The hzrproc (HZR) ships in the SYS1.PROCLIB data
set.</li>
<li>If you want to start Runtime Diagnostics address space (HZR) during
system initialization, specify <samp class="xph">COM='S HZR,SUB=MSTR'</samp> in
the COMMND<span class="synph"><span class="var">xx</span></span> parmlib member. Otherwise,
the HZR address space must be started manually: <samp class="xph">S HZR,SUB=MSTR</samp></li>
<li>After the Runtime Diagnostics address space (HZR) is started,
use the <samp class="xph">MODIFY HZR,ANALYZE</samp> command to generate Runtime
Diagnostics' reports.</li></ol>
<p><strong>Reference information</strong>: For complete details about using
Runtime Diagnostics, see the topic on  in <cite>z/OS Problem Management</cite>.</p>
<h4 id="operloge">Accommodate OPERLOG EMCS console name change</h4>
<p>[[[[ Contributing writer: Shigeki Kimura/Japan/IBM@IBMJP
]]]] [[[[ Technical contact: Shigeki Kimura/Japan/IBM@IBMJP, Richard
Bibolet/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: The OPERLOG EMCS console name *OPLOG<span class="synph"><span class="var">yy</span></span> is
generated using the two character System Clone value (&amp;SYSCLONE).
The default &amp;SYSCLONE value is obtained from the System Name (&amp;SYSNAME)
(for example, System Name = SYSTEM1 / System Clone = M1 ). This naming
convention is similar to the SYSLOG EMCS console (*SYSLG<span class="synph"><span class="var">yy</span></span>).<a id="idx745"></a></p>
<table id="wq395" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13 (z/OS V1R12, z/OS V1R11, z/OS V1R10,
and z/OS V1R9 by APAR OA31913).</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12 without the PTF for APAR OA31913
applied.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you depend on the OPERLOG EMCS console
name.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td> None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: The change of OPERLOG EMCS console name spans
all configurations (MULTISYSTEM, XCFLOCAL, MONOPLEX, in GRS RING or
STAR mode). If you depend on the name of OPERLOG EMCS console in your
own procedure, it must be adjusted to reflect this change. For example,
the following will display the OPERLOG EMCS console name: </p>
<pre class="xmp"><code>D C,KEY=OPERLOG (message IEE892I)
D EMCS (message IEE129I)
D EMCS,CN=*OPLOG* (message IEE129I)</code></pre><p class="indatacontent">  </p>
<div>
<div class="note-noindent" id="wq396">
<span class="notetitle">Note:</span> <span class="notebody">With z/OS V1R12,
this change was already in effect.</span></div></div>
<p><strong>Reference information</strong>: For more information about the OPERLOG
EMCS console, see <cite>z/OS MVS Planning: Operations</cite>.</p>
<h4 id="oa35357">Change value for ARM restart processing</h4>
<p>[[[[ Contributing writer: James J Guilianelli/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Neil Johnson/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Before performing cross-system restart, automatic
restart management (ARM) waits for member cleanup for the terminated
system to complete. ARM proceeds with cross-system restart if cleanup
takes longer than a certain amount of time. Before z/OS V1R13, this
time was two minutes. Support for a new parameter, CLEANUP_TIMEOUT,
is available with the PTFs for APAR OA35357 applied to z/OS V1R13
and z/OS V1R12. The default for this new parameter is five minutes.
That is, ARM will wait five minutes for member cleanup for a terminated
system to complete before performing cross-system restart for an element.</p>
<p>Starting with z/OS V1R13, the CLEANUP_TIMEOUT parameter can be
used to indicate that ARM is to wait additional time for member cleanup
for a terminated system to complete. To get the two minute timeout
behavior that existed before the default change, CLEANUP_TIMEOUT(120)
 must be added to the ARM policy. If you do not specify CLEANUP_TIMEOUT(120),
the system issues the following message to the system log to record
when CLEANUP_TIMEOUT has an effect on cross-system restart processing: </p>
<pre class="xmp"><code>IXC815I MEMBER CLEANUP FOR SYSTEM <span class="synph"><span class="var">sysname1</span></span> NUMBER <span class="synph"><span class="var">sysnum1</span></span> INCOMPLETE</code></pre>
<p>        <a id="idx746"></a><a id="idx747"></a></p>
<table id="wq397" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13, and rolled back to z/OS V1R12, z/OS
V1R11, and z/OS V1R10 by APAR OA35357.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12 without the PTFs for OA35357 applied.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if a five-minute timeout for member cleanup
is not acceptable.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>The new five minute default, or any use of the
CLEANUP_TIMEOUT parameter other than CLEANUP_TIMEOUT(120), is not
fully effective until all systems in the sysplex have support for
the CLEANUP_TIMEOUT parameter. APAR OA35357 provides support for the
CLEANUP_TIMEOUT parameter.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If you prefer to use the two minute value
for ARM restart processing, do the following:</p>
<ol type="1">
<li>Use the z/OS V1R13 version of IXCMIAPU to define an ARM policy
with CLEANUP_TIMEOUT(120).</li>
<li>Use the SETXCF START command to start the new or updated policy.</li></ol>
<p><strong>Reference information</strong>: For details, see the topic "Automatic
restart management parameters for administrative data utility" in
the chapter "Administrative data utility" in <cite>z/OS MVS Setting Up a Sysplex</cite>.</p>
<h4 id="pfaparm">Provide the <span class="synph"><span class="var">migrate</span></span> or <span class="synph"><span class="var">new</span></span> parameter
when running the PFA install script</h4>
<p>[[[[ Contributing writer: Jodi E Everdon/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contacts : Karla Arndt/Rochester/IBM@IBMUS and
Ashvin Desai/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R12,
when installing Predictive Failure Analysis (PFA) it was not necessary
for you to specify how to handle the existing data in the check directories.
Beginning with z/OS V1R12,
you must append a parameter, <span class="synph"><span class="var">migrate</span></span> or <span class="synph"><span class="var">new</span></span>,
on the installation script to specify if the PFA check directories
retain data from the prior release. If you do not append the <span class="synph"><span class="var">migrate</span></span> or <span class="synph"><span class="var">new</span></span> parameter,
the AIRSHREP.sh script fails.</p>
<table id="wq399" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx748"></a><a id="idx749"></a><a id="idx750"></a><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are using PFA.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>Refer to <cite>z/OS Problem Management</cite> for
considerations and actions required for Predictive Failure Analysis
(PFA) when falling back to z/OS V1R12
from z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Provide the <span class="synph"><span class="var">migrate</span></span> or <span class="synph"><span class="var">new</span></span> parameter
when running the PFA install script, AIRSHREP.sh, or when using the
sample JCL for batch provided in SYS1.SAMPLIB.  
</p>
<ul>
<li><span class="synph"><span class="var">migrate</span></span>: Use the <span class="synph"><span class="var">migrate</span></span> parameter
to preserve PFA history data from the prior release. The <span class="synph"><span class="var">migrate</span></span> option
is recommended for all installations that previously used PFA. When
you specify the <span class="synph"><span class="var">migrate</span></span> parameter, the install
script preserves data from the prior release and creates new directory
structures for checks not previously installed on your system.</li>
<li><span class="synph"><span class="var">new</span></span>: Use the <span class="synph"><span class="var">new</span></span> parameter
if you are installing PFA for the first time or if you want to delete
everything from prior releases and start PFA with new directories.
When you specify the <span class="synph"><span class="var">new</span></span> parameter, the
install script deletes the existing check directories and creates
a new directory structure for all the checks.</li></ul>
<p>For example, to run the install script from your home directory:</p>
<ol type="1">
<li>On the OMVS command line, go to the home directory for
the PFA user: <samp class="xph">cd var/pfa</samp></li>
<li>Run the install script appending the migrate parameter:  <samp class="xph">/usr/lpp/bcp/AIRSHREP.sh
migrate</samp></li></ol>
<p><strong>Reference information</strong>: For complete details, see the topic
on  in <cite>z/OS Problem Management</cite>.</p>
<h4 id="oa34731">Issue commands from the system console regardless of problem
determination mode</h4>
<p>[[[[ Contributing writer: Rita M Beisel/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Peter Fatzinger/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><a id="idx751"></a><a id="idx752"></a><strong>Description</strong>:
Before z/OS V1R12, the system console could not issue any commands
(except <span class="synph"><span class="kwd">REPLY</span></span> and <span class="synph"><span class="kwd">VARY CN(*),ACTIVATE</span></span>)
unless it was placed in problem determination (PD) mode through the <span class="synph"><span class="kwd">VARY
CN(*),ACTIVATE</span></span> command. Starting with z/OS V1R12, processing
changed so that commands could always be entered at the system console
regardless of problem determination mode. With APAR OA34731, commands
can only be entered at the system console if the <span class="synph"><span class="kwd">CONSOL</span></span><em>xx</em> keyword
ALLOWCMD(Y) is specified on the system console definition.</p>
<table id="wq401" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx753"></a><a id="idx754"></a><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R12 with APAR OA34731 and z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td> z/OS V1R12 without the PTF for OA34731 installed.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if it applies to migration from: z/OS V1R12
without the PTF for OA34731, and you wish to override the default
of ALLOWCMD(N) introduced in OA34731 (and integrated into higher releases)
to allow the system console issue the commands regardless of problem
determination mode.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>The parmlib statement <span class="synph"><span class="kwd">ALLOWCMD</span></span> in <span class="synph"><span class="kwd">CONSOL</span></span><em>xx</em> 
is not tolerated on systems that do not have the PTF for APAR OA34731
installed.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>Use CHECK(CNZ_SYSCONS_ALLOWCMD) to compare the <span class="synph"><span class="kwd">ALLOWCMD</span></span> setting
for the system console with the setting specified on the check.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Add <span class="synph"><span class="kwd">ALLOWCMD(Y)</span></span> to
the system console definition in the <span class="synph"><span class="kwd">CONSOL</span></span><em>xx</em> member
of PARMLIB if you wish to allow commands to be issued from the system
console regardless of problem determination mode.</p>
<p><strong>Reference information</strong>: 
</p>
<ul>
<li>For CONSOLExx, see <cite>z/OS MVS Initialization and Tuning Reference</cite>.</li>
<li>PTF HOLD information for APAR OA34731.</li></ul>
<h3 id="dt2mg564">BCP actions to perform after the first IPL of z/OS V2R1</h3>
<p>This topic describes BCP migration actions that you can perform
only after you have IPLed z/OS V2R1.
You need a running z/OS V2R1
system to perform these actions.</p>
<p><a href="e0z3m100.htm#dt2mg304">Do not disable TRACKDIRLOAD</a></p>
<p><a href="e0z3m100.htm#li2657d">Accommodate the SETLOAD IEASYM command to update system symbols
without initiating an IPL</a></p>
<p><a href="e0z3m100.htm#cpccdef">Plan for  discontinuation of enhancements to the Windows-based
Capacity Provisioning Control Center (CPCC) for use with z/OS MVS
Capacity Provisioning</a></p>
<p><a href="e0z3m100.htm#grsficon1">Migrate to GRS-managed FICON CTCs</a></p>
<p><a href="e0z3m100.htm#cmdsabe">Examine use of the CMDS ABEND command</a></p>
<p><a href="e0z3m100.htm#rtdpfa">Start Runtime Diagnostics to enhance Predictive Failure Analysis</a></p>
<p><a href="e0z3m100.htm#dt2mg580">Carry over your existing CPCC policy</a></p>
<p><a href="e0z3m100.htm#pfamax">Add to the maximum number of open files under z/OS UNIX Systems
Services for PFA</a></p>
<p><a href="e0z3m100.htm#grsauthql">Set AUTHQLVL parameter in GRSCNFxx parmlib member to recognize
new GRS qnames</a></p>
<h4 id="dt2mg571">Do not disable TRACKDIRLOAD</h4><a id="idx755"></a>
<p></p>
<p><strong>Description</strong>: TBD</p>
<table id="wq402" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td></td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After
the first IPL of V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td></td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<p><strong>Reference information:</strong></p>
<h4 id="dt2mg572">Accommodate the SETLOAD IEASYM command to update system symbols
without initiating an IPL</h4><a id="idx756"></a><a id="idx757"></a><a id="idx758"></a><a id="idx759"></a><a id="idx760"></a>
<p><strong>Description</strong>: Before z/OS V2R1, the downloadable
SYMUPDTE routine and the IEASYMUP module in SAMPLIB were provided
as mechanisms to update system symbols without initiating an IPL.
Starting with z/OS V2R1, the SETLOAD xx,IEASYM command is available
to perform this task. In z/OS V2R1, the <span>IEASYMUP</span> module
in SAMPLIB is updated to return with a RC=999, not having done the
requested function. However, unless this IEASYM module is rebound,
there is no way to prevent the usage of an old copy, or detect an
update due to use of an old copy of the tool.<a id="idx761"></a></p>
<table id="wq403" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are currently using the IEASYM module
provided in SAMPLIB or the SYMUPDTE routine to update system symbols.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>If you continue to use an obsolete method (SYMUPDTE
routine or the IEASYMUP module) , the system will continue to function
properly until the SETLOAD xx,IEASYM command is used, at which point
updates introduced by those other programs will be lost.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>SUP_SYSTEM_SYMBOL_TABLE_SIZE. This code checks
if the size of the static system symbol table has exceeded the threshold.
This check is initially run once and is also run when the SETLOAD
xx.IEASYM command is successfully processed.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Rebind the IEASYMUP module from
the z/OS V2R1 SAMPLIB to disable the code or simply remove it from
LINKLIB or your LNKLST library. If you have used the SYMUPDTE downloadable
module, remove it from your LINKLIB or your LNKLST library.
Begin using SETLOAD xx,IEASYM command instead of these obsolete modules.</p>
<p><strong>Reference information</strong>: The "SETLOAD command" in <cite>z/OS MVS System Commands</cite> and
"System Symbols" in <cite>z/OS MVS Initialization and Tuning Reference</cite></p>
<p>For information on the
IEASYMUP module or the SYMUPDTE routine, see <em>z/OS Planned Outage
Avoidance Checklist</em> at the IBM Redbooks site:
</p>
<ul>
<li>
<p><a href="http://www.ibm.com/support/us/en/?lnk=msd-0-usen" target="_blank">Support &amp;
downloads</a></p></li></ul><p class="indatacontent"> the Redbooks site at <a href=" http://www.ibm.com/redbooks">http://www.redbooks.ibm.com/abstracts/sg247328.html?Open</a>.</p>
<h4 id="dt2mg573">Plan for  discontinuation of enhancements to the Windows-based
Capacity Provisioning Control Center (CPCC) for use with z/OS MVS
Capacity Provisioning</h4>
<p>[[[[ Contributing writer: Wolf-Dieter
Hahn/Germany/IBM@IBMDE ]]]] [[[[ Technical contact: Michael Groetzner/Germany/IBM@IBMDE
]]]]</p>
<p><strong>Description</strong>: /OS V1R13 is the last release to provide enhancements
to the Windows-based Capacity Provisioning Control Center (CPCC) function
for use with z/OS MVS Capacity Provisioning. As of z/OS V2R1, IBM
provides an alternative means to define Capacity Provisioning polices
and to add function to the z/OSMF-based Capacity Provisioning application
to allow you to control your Capacity Provisioning function.<a id="idx762"></a><a id="idx763"></a></p>
<table id="wq404" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1?</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to continue using your existing
CPCC workspace.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>????</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Move to the function for CPPC provided by
z/OS V2R1??????????</p>
<p><strong>Reference information</strong>: For more information about installing
and uninstalling CPCC, see <cite>z/OS MVS Capacity Provisioning User&amp;apos;s
Guide</cite>.</p>
<h4 id="grsficon1">Migrate to GRS-managed FICON CTCs</h4><a id="idx764"></a><a id="idx765"></a><a id="idx766"></a><a id="idx767"></a><a id="idx768"></a>
<p>[[[[ Contributing writer: &lt;Debra A
Quick/Somers/IBM@IBMUS &gt; ]]]] [[[[ Technical contact: &lt;Bryan
Childs/Poughkeepsie/IBM &gt; ]]]]</p>
<p><strong>Description</strong>: Before OA38230, GRS could only manage
CTCs running in basic mode. Starting with APAR OA38230 (on z/OS V1R11,
z/OS V1R12, and z/OS V1R13, and incorporated into z/OS V2R1), GRS
can additionally manage FICON CTCs
(FCTC), which run in extended mode.<a id="idx769"></a></p>
<p>Migrate GRS-managed basic-mode CTCs to GRS-managed FICON CTCs in order to run in extended mode.
Note that GRS star continues to be the recommended configuration for
global ENQ/DEQ processing because of its better performance and overall
reliability, availability, and serviceability (RAS).  If the installation
requires a GRS ring, IBM suggests
that the GRS complex equals the sysplex, as it provides a more robust
transport layer for its communications.</p>
<table id="wq405" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13, z/OS V1R12 and z/OS V1R11 with APAR OA38230.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td> z/OS V1R12
without APAR OA38230.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td> 

<p>Yes, if you meet the conditions
mentioned below in this description and you are running on a zEC12
server or higher. See the hardware release memorandum RFA z196 for
further information. <a href="http://www-01.ibm.com/common/ssi/rep_ca/0/897/ENUS110-170/ENUS110-170.PDF">http://www-01.ibm.com/common/ssi/rep_ca/0/897/ENUS110-170/ENUS110-170.PDF</a></p> 

<p>This
migration action only applies to installations where GRS directly
manages CTCs as specified in GRSCNF<span class="synph"><span class="var">xx</span></span>. There
are two applicable configurations: 
</p>
<ul>
<li>A GRS Ring where the GRS complex is greater than the sysplex,
or</li>
<li>A GRS ring that does not utilize sysplex communications at all.</li></ul> 

<p>If you are running GRS Star, or using embedded XCF communications
links rather than GRS-managed CRCs, this migration action is not applicable
to you.</p></td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>Until each system that communicates with another
system is configured to use FCTCs, GRS will be unable to use that
FCTC.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>IBM Health
Checker for z/OS check GRS_MODE
can help you determine if you are running GRS Star or ring. If this
check indicates that you are running GRS Star (the recommendation),
then this migration action is not applicable to you. If this check
indicates that you are running GRS ring, then this migration action
may be applicable as described in the section above: "Is this migration
action required?"</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: There are two separate methods to migrate
to the updated GRSCNFxx members with the additional FICON CTC, depending on the needs of the installation.</p>
<p><strong>Initial preparation</strong>:</p>
<p>Regardless of the migration method chosen, there is some initial
preparation: 
</p>
<ul>
<li>Apply the program temporary fixes (PTFs) for OA38230 to all the
systems before an IPL of any system.</li>
<li>Make sure all FICON CTC
adapters, in addition to the existing ESCON basic
channel-to-channel (BCTC) adapters, have the proper configuration
and connection to each z/OS system
in the GRS complex.</li>
<li>Determine the FICON CTC
adapter device numbers from the hardware configuration.</li>
<li>Add the corresponding FICON CTC
device numbers to the end of the existing list for GRSCNFxx members
used across the complex, as shown in the example.</li></ul>
<p>GRS-managed CTC devices are solely for the use of GRS and cannot
be added to the system dynamically. The CTC devices must be defined
in GRSCNFxx at IPL time. Also recall that the order of the CTC devices
listed in GRSCNFxx is significant for any given remote system. The
CTC device listed last is the first CTC device considered for primary
usage. Provided GRS&rsquo; initialization of that CTC device is successful,
the next-to-last CTC device gets set up as an alternate, the next
as an additional alternate, and so forth. If your installation is
testing the GRS FICON CTC
support on hardware that supports ESCON, IBM recommends adding, rather than
replacing, the FICON CTC device
numbers below the existing CTC device numbers, as shown in example.</p>
<p><strong>Example</strong>:</p>
<p>A GRSCNFxx CTC example. </p>
<pre class="xmp"><code>/*********************************************************************/
/* IN THIS EXAMPLE,                                                  */
/* DEVICE NUMBERS BETWEEN 0500 AND 05FF ARE BCTCS                    */
/*                        8100 AND 81FF ARE FCTCS                    */
/*********************************************************************/
GRSDEF                                                                 
  MATCHSYS(*)                                                          
  CTC(5C0)  /* prospective 3rd alternate - BCTC                      */
  CTC(5DF)  /* "           2nd alternate - BCTC                      */
  CTC(8100) /* "           alternate     - FCTC                      */
  CTC(811F) /* "           primary       - FCTC                      */</code></pre>
<p>There are two separate ways to migrate to the updated GRSCNFxx
members with the additional FICON CTC
devices, depending on the needs of the installation.</p>
<p><strong>Migration method: rolling IPL</strong></p>
<p>Migrating to FICON CTC
communication means a planned outage because at least one system remains
active in the current GRS ring throughout the migration. The advantage
of performing a rolling IPL is that it allows for better availability.</p>
<p>Use the following procedure to minimize the chance of a ring disruption
in the migration of GRS-managed CTC communication:</p>
<ol type="1">
<li><strong>Follow your normal procedures for bringing down the system
and preparing to IPL.</strong> Don't forget to enter the Z EOD command
to write buffered system management facilities (SMF) records, and
system log and LOGREC data, and wait for message IEE3341: HALT EOD
SUCCESSFUL.</li>
<li><strong>Quiesce the systems from the ring.</strong> On any system, enter
the VARY GRS(X),QUIESCE command. Wait for message ISG013I; SYSTEM
X QUIESCED GLOBAL RESOURCE SERIALIZATION. The VARY GRS(X),QUIESCE
command is important because it prevents a ring disruption from removing
the QUIESCED system. You can only use VARY GRS(X),QUIESCE when there
is at least one XCF=local or monoplex system in the complex using
CTC communication.</li>
<li><strong>Stop the system.</strong> Now it is safe to stop system X. Do so
by initiating a system reset on the hardware management console (HMC).
For Parallel Sysplex,
the sysplex failure management (SFM) policy and the status update
missing intervals (specified on the INTERVAL keyword in COUPLExx)
start counting down as soon as you use the system reset.</li>
<li><strong>Purge the system from the ring.</strong> After system X stops, it
is an XCF=local system or a monoplex. On any system, issue VARY GRS(X),PURGE.
If system X is a member of a sysplex, issue VARY XCF,X,OFFLINE and
respond to the prompts as usual. In either case, wait for message
ISG013I: SYSTEM X PURGED FROM GRS COMPLEX, which means system X is
removed from the ring.</li>
<li><strong>IPL with a new GRSCNFxx.</strong> IPL system X. When the system
is ready, issue D GRS to verify the system (and the other systems).
It should show up as "ACTIVE" in the existing GRS ring. If the JOIN
process on the existing ring fails, make sure GRSCNFxx is correct
and the purge of the previous instance from the ring was successful.
Try this step again.</li>
<li><strong>Check the CTC devices.</strong> Verify that the D GRS output
lists the new CTC device numbers as IN-USE, ALTERNATE or conditionally
QUIESCE. If the CTC device is IN-USE or ALTNERATE, the TARGET SYSNAME
field must be accurate. If a CTC status is QUIESCE, it is online,
but the other side of the CTC device is not communicating. If the
system on the other side of the CTC device has not been re-IPLed to
pick up the new CTC definitions, then QUIESCE status is expected.
Scenario II in <a href="e0z3m100.htm#grsficon1__rollipl1">Figure 1</a> shows that
GRS will not attempt to use a new CTC device until the system at the
other side of the link is re-IPLed to pick up its corresponding CTC
device. If all of the systems are running with the new CTC device,
it is unusual that the CTC device remains QUIESCE. If there are one
or more QUIESCE CTC devices, look for a CTC problem on the system
at the other end of the link. If the CTC device is unexpectedly DISABLED,
look for the corresponding ISG046E message from the SYSLOG. There
is probably a parmlib member or device configuration issue. After
you address the issue, try to VARY the device online.</li>
<li><strong>Repeat steps 1 through 6</strong> for each system in the GRS ring.</li></ol>
<p> 
</p>
<div class="fignone" id="grsficon1__rollipl1"><span class="figcap"><a href="e0z3m100.htm#FT_Figure_1">Figure 1. Example of a rolling IPL on a three-system GRS ring</a></span>
<div class="mmobj">
<img src="e0z3grs1.gif" alt="REQTEXT" /></div></div>
<p><a href="e0z3m100.htm#grsficon1__rollipl1">Figure 1</a> illustrates how the rolling
IPL eventually starts using the new FICON CTC
(FCTC) devices. After the first system is restarted with the original
CTC and FCTC devices (scenario II in <a href="e0z3m100.htm#grsficon1__rollipl1">Figure 1</a>),
GRS continues to use the original CTC device and JOIN the existing
GRS ring. However, as the second and third system are restarted (scenario's
III and IV in <a href="e0z3m100.htm#grsficon1__rollipl1">Figure 1</a>), GRS uses
the FCTC rather than the BCTC because on IPLing system, GRS always
tries to initialize the CTC devices in last-to-first order as they
appear in GRSCNFxx.</p>
<p><strong>Migration method: complex-wide IPL</strong></p>
<p>A GRS complex-wide IPL depends on the installation's policies and
procedures regarding planned outages of that scale. The preparation
is the same with regard to applied PTF, FICON setup, and GRSCNFxx settings. The orderly
shutdown can use the same initial steps to avoid ring disruptions.</p>
<p>In the case of a mixed complex, it is important for the last system
to be an XCF=local or monoplex system. Whenever a mixed GRS complex
transitions into a pure sysplex, VARY GRS(X) is no longer allowed.
It is also recommended that you IPL that system alone with GRS=START
to establish the ring of one with all of its CTC devices QUIESCE before
starting the remaining systems. See <a href="e0z3m100.htm#grsficon1__tryjoin1">***</a>.</p>
<p id="grsficon1__tryjoin1"><strong>TRYJOIN Warning</strong></p>
<p>Do not use GRS=TRYJOIN if any systems in the GRS complex use GRS-managed
CTC communication. When the GRS complex equals the sysplex, the TryJoin
option is planned to resolve correctly. In a mixed up ring or a ring
where GRS manages all of its CTC communication directly, a single
system should specify GRS=START and the remainder GRS=JOIN. Otherwise,
there exists a race condition for the initializing systems to form
a split ring where data integrity is compromised. This is still true
with FICON CTC support.</p>
<p><strong>Reference information</strong>: 
</p>
<ul>
<li>For more information, see <cite>z/OS MVS Planning: Global Resource Serialization</cite>.</li>
<li>For more information on CTC definitions, see: 

<ul>
<li><cite>z/OS HCD User&amp;apos;s Guide</cite></li>
<li><cite>z/OS HCD Planning</cite></li>
<li><cite>z/OS HCD Reference Summary</cite>.</li></ul></li></ul>
<h4 id="cmdsabe">Examine use of the CMDS ABEND command</h4>
<p>[[[[ Contributing writer: Rita M Beisel/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Richard Bibolet/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: <span>Before z/OS V1R13, the
CMDS ABEND command ended an executing command if the command was hung.
In z/OS V1R12, the command processors were allowed to specify the
new non-abendable attribute to set themselves non-abendable. When
the new attribute was specified for a target command, the CMDS ABEND
command rejected with the following message: <samp class="xph">CNZ6002I COMMAND <em>command</em> WITH
ID <em>id</em> NOT ABENDABLE</samp>. The CMDS ABEND attempted to terminate
the hung command.</span>. Starting in z/OS V1R13, the new parameter
FORCE is added to the CMDS command so that a CMDS FORCE specification
overrides the non-abendable attribute and the command will be terminated
as it is today. Separating the ABEND and FORCE requests allow different
RACF profiles to be defined so that installations can allow CMDS ABEND,
but not CMDS FORCE. FORCE is intended to be used where the only alternative
is to re-IPL the system.</p>
<p></p>
<table id="wq407" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx770"></a><a id="idx771"></a><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if you use the CMDS ABEND
command or have automation that does.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Automation that uses the CMDS ABEND command
is affected because the termination of a running command can be rejected.
For some commands, this rejection is important because it can prevent
a system or sysplex outage. If you use the CMDS ABEND command or have
automation that does, certain commands will no longer be terminated
by the CMDS ABEND command. 
</p>
<ul>
<li>If you must terminate a command, continue to use the CMDS ABEND
command. If the command is in a state making it non-abendable, use
the CMDS FORCE command after understanding the following recommendations
associated with the FORCE parameter:  

<ul>
<li>After issuing CMDS FORCE, you might have to re-IPL the system
or, depending on the command being terminated, a sysplex-wide IPL
may be required.</li>
<li>You should ensure that the target command is hung and not just
requiring additional time to complete.</li></ul></li></ul>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li>For details about the CMDS command, see <cite>z/OS MVS System Commands</cite>.</li>
<li>See message CNZ6002I in <cite>z/OS MVS System Messages, Vol 4 (CBD-DMO)</cite>.</li></ul>
<h4 id="rtdpfa">Start Runtime Diagnostics to enhance Predictive Failure Analysis</h4>
<p>[[[[ Contributing writer: Jodi E Everdon/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contacts: Karla Arndt/Rochester/IBM@IBMUS, Donald
Durand/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Beginning with z/OS V1R13, Predictive Failure
Analysis (PFA) calls Runtime Diagnostics to analyze and report insufficient
metric activity from the following checks: 
</p>
<ul>
<li>PFA_ENQUEUE_REQUEST_RATE</li>
<li>PFA_MESSAGE_ARRIVAL_RATE</li>
<li>PFA_SMF_ARRIVAL_RATE</li></ul>
<p>In order for these checks to produce exceptions when the
metrics are too low, PFA needs the Runtime Diagnostics address space
(HZR) to be active. If it is not, PFA can only issue exceptions for
these metrics when the rates are too high. <a id="idx772"></a><a id="idx773"></a><a id="idx774"></a></p>
<table id="wq408" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you wish to have the Runtime Diagnostic
information in the PFA check report for the following checks:

<ul>
<li>PFA_ENQUEUE_REQUEST_RATE</li>
<li>PFA_MESSAGE_ARRIVAL_RATE</li>
<li>PFA_SMF_ARRIVAL_RATE</li></ul></td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>If you continue to use an obsolete method (SYMUPDTE
routine or the IEASYMUP module) , the system will continue to function
properly until the SETLOAD xx,IEASYM command is used, at which point
updates introduced by those other programs will be lost.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>If RTD isn't running and PFA calls it, the call
to RTD returns with a return code of 12 and a reason code of 3074
(C02), and PFA processing skips the potential exception because it
could not be confirmed through RTD (as in previous releases without
this z/OS V1R13 enhancement). If or when RTD ever becomes active,
then the calls will become successful.  The return code and reason
code are logged in the <em>systemname</em>RUN.LOG for the
check, as follows:  
<pre class="xmp"><code>Calling to determine too low 
Return code = 0000000C 
Reason code = 00000C02</code></pre></td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Ensure the HZR is defined as a system address
space. <span>See <a href="e0z3m100.htm#commndxx">Start Runtime Diagnostics at system initialization</a> .</span></p>
<p><strong>Reference information</strong>: For complete details about using
Runtime Diagnostics, see the topics  and  in <cite>z/OS Problem Management</cite>.</p>
<h4 id="dt2mg580">Carry over your existing CPCC policy</h4>
<p>[[[[ Contributing writer: Wolf-Dieter
Hahn/Germany/IBM@IBMDE ]]]] [[[[ Technical contact: Michael Groetzner/Germany/IBM@IBMDE
]]]]</p>
<p><strong>Description</strong>: The Capacity Provisioning Control Center (CPCC)
can coexist with older versions of the CPCC on a workstation. However,
z/OS V1R13 CPCC uses a different default workspace. If you want to
continue using your existing CPCC workspace, point to the respective
directory during the installation of z/OS V1R13 CPCC. It is also possible
to change the workspace when the CPCC starts.<a id="idx775"></a><a id="idx776"></a></p>
<table id="wq409" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to continue using your existing
CPCC workspace.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td><span>You must run a level of the CPCC
client that corresponds to the z/OS system that you target. </span>For
example, run the z/OS V1R13 CPCC client on the workstation when interacting
with the z/OS V1R13 Capacity Provisioning Manager, and run the z/OS
V1R12 CPCC client on the workstation when interacting with the z/OS
V1R12 Capacity Provisioning Manager.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ul>
<li>Install z/OS V1R13 CPCC using information in documentation referenced
below. 
<div>
<div class="note-noindent" id="wq410">
<span class="notetitle">Note:</span> <span class="notebody">With z/OS V1R13, the location of the default workspace
changes from, for example,  <samp class="xph">C:\Documents
and Settings\user\Application Data\IBM\IBM Capacity  Provisioning
Control Center</samp>      

<p>to</p><samp class="xph">C:\Documents
and Settings\user\Application Data\IBM\IBM Capacity Provisioning Control
Center V1R13\</samp>   

<p>The actual directories depend on the Windows
version that you are using.</p></span></div></div></li>
<li>If you want to continue using your existing (pre-z/OS V1R13) CPCC
workspace, point to the desired workspace during the installation
process. You can also switch the workspace at a later time by navigating
to the desired workspace when the CPCC starts.</li></ul>
<p><strong>Reference information</strong>: For more information about installing
and uninstalling CPCC, see <cite>z/OS MVS Capacity Provisioning User&amp;apos;s
Guide</cite>.</p>
<h4 id="pfamax">Add to the maximum number of open files under z/OS UNIX Systems
Services for PFA</h4>
<p>[[[[Neil Shah]]]]</p>
<p><strong>Description</strong>: Starting in z/OS V1R13, Predictive Failure
Analysis (PFA) has two  additional checks, PFA_JES_SPOOL_USAGE and
PFA_ENQUEUE_REQUEST_RATE. These additional checks add to the number
of open files for the PFA started task id. <a id="idx777"></a></p>
<table id="wq411" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V1R13 and before
the start of PFA.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use PFA  and MAXFILEPROC is less
than 5000. 

<p></p></td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: PFA requires the maximum number of open files
under z/OS UNIX System Services to be 5000 or greater. You can increase
the value in one of two ways. The first option is preferable:</p>
<ol type="1">
<li>Update the FILEPROCMAX field in the OMVS segment of the PFA started
task id, for example:  
<pre class="xmp"><code>TSO ALU pfauser  OMVS(FILEPROCMAX(5000))</code></pre></li>
<li>Update the BPXPRMxx MAXFILEPROC value in the parmlib member BPXPRMxx.</li></ol>
<p><strong>Reference information</strong>: For more information about the MAXFILEPROC
value, see <cite>z/OS MVS Initialization and Tuning Reference</cite>.</p>
<p>For information about FILEPROCMAX, see <cite>z/OS Security Server RACF General User&amp;apos;s Guide</cite>.</p>
<h4 id="grsauthql">Set AUTHQLVL parameter in GRSCNFxx parmlib member to recognize
new GRS qnames</h4><a id="idx778"></a><a id="idx779"></a><a id="idx780"></a>
<p>[[[[ Contributing writer: James J Guilianelli/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Bryan Childs/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Beginning with z/OS V1R13, global resource
serialization (GRS) provides an additional list of qnames that are
conditionally authorized: ARCDSN, ARCBTAPE, ARCGPA, ARCBACV, and ARCMIGV.
You can set the new AUTHQLVL parameter in the GRSCNF<span class="synph"><span class="var">xx</span></span> parmlib
member to indicate whether the system is to recognize the second list
of authorized qnames in addition to the original list. The value is
either 1 (default) or 2.</p>
<p>The AUTHQLVL setting of 1 (default) denotes that the existing IBM
default list for authorized qnames (that is, the list in effect for
systems at z/OS V1R12 and earlier) is in effect for the system in
the global resource serialization (GRS) complex. The AUTHQLVL setting
of 2 denotes the addition of the five new qnames (ARCDSN, ARCBTAPE,
ARCGPA, ARCBACV, ARCMIGV) to the authorized qname list and provides
a higher level of protection; however, it can cause some products
to fail. An unauthorized program issuing ENQ or DEQ requests for any
of these qnames when AUTHQLVL of 2 is in effect will get ABEND338
or ABEND330, respectively.  ISGENQ requests with COND=NO will get
similar ABENDs and ISGENQ requests with COND=YES will get return code
8, reason code xxxx081E, ISGENQRsn_NotAuthorizedForQName.</p>
<table id="wq413" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>BCP</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, to protect authorized programs utilizing
these qnames from denial-of-service attacks.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>Use check GRS_AUTHQLVL_SETTING to help determine
your installation's need for authorized qname protection.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Products that are designed to interact with resources that have
these qnames need to run authorized.  In order to help determine if
your installation has any of these products running on your system,
there is a new AUTHQ2 filter on the EQDQ Monitor.  Before the new
AUTHQLVL is increased to 2, this filter shows ENQ requests that are
made with any of these new qnames from an unauthorized program.</li>
<li>The AUTHQLVL setting in GRSCNF<span class="synph"><span class="var">xx</span></span> refers
to a specific system.  A rolling IPL is required to ensure consistency
across the GRS complex.  The increased AUTHQLVL value can be tested
on one system but only for ENQ requests initiated on that system.
The AUTHQLVL=2 migration process is not complete until all systems
across the GRS complex are at 2.</li>
<li>If ABEND338 or ABEND330 occurs from the change because one of
the required products is missed, the <span class="synph"><span class="kwd">SETGRS</span></span> command
supports a fallback to 1 on any given system by issuing <span class="synph"><span class="kwd">SETGRS
AUTHQLVL=1</span></span>; however, you cannot dynamically increase
the AUTHQLVL.  Another IPL is required. As with other SETGRS keywords
that require UPDATE access to an OPERCMDS profile matching an MVS.SETGRS.<span class="synph"><span class="var">xxx</span></span> profile
name, downgrading the AUTHQLVL to 1 through the SETGRS command in
an OPERCMDS environment requires update access to a profile of the
form MVS.SETGRS.AUTHQLVL</li></ol>
<p><strong>Reference information</strong>: For details about authorized qnames,
see <cite>z/OS MVS Planning: Global Resource Serialization</cite>.</p>
<h2 id="dt2mg581">BookManager BUILD migration actions</h2>
<p>This topic describes migration actions for optional feature BookManager
BUILD.</p>
<h3 id="dt2mg582">BookManager BUILD actions to perform before installing z/OS
V2R1</h3><a id="idx781"></a>
<p>This topic describes BookManager BUILD migration actions that you
can perform on your current (old) system. You do not need the z/OS
V2R1 level of code to make these changes, and the changes do not require
the z/OS V2R1 level of code to run once they are made.</p>
<p><a href="e0z3m100.htm#bookmanagersod">Plan for the removal of support for the optional feature BookManager
BUILD</a></p>
<h4 id="dt2mg583">Plan for the removal of support for the optional feature BookManager
BUILD</h4><a id="idx782"></a>
<p></p>
<p><strong>Description</strong>: z/OS
V2R1 is the last release that is planned to support the optional feature
BookManager BUILD of z/OS. Plan for the removal of support.</p>
<table id="wq415" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>BookManager
BUILD</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes,
if you use the optional feature BookManager BUILD.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<p>Remove support of BookManager BUILD for releases of z/OS later
than z/OS V2R1.</p>
<p><strong>Reference information:</strong> 
See Statement of Direction????????</p>
<h3 id="dt2mg584">BookManager BUILD actions to perform before the first IPL of
z/OS V2R1</h3>
<p>This topic describes BookManager BUILD migration actions that you
can perform after you have installed z/OS V2R1 but before the first
time you IPL. These actions might require the z/OS V2R1 level of code to be installed but
do not require it to be active.</p>
<p>None.</p>
<h3 id="dt2mg585">BookManager BUILD actions to perform after the first IPL of
z/OS V1R13</h3>
<p>This topic describes BookManager BUILD migration actions that you
can perform only after you have IPLed z/OS V2R1. You need a running
z/OS V2R1 system to perform these actions.</p>
<p>None.</p>
<h2 id="cim">CIM migration actions</h2>
<p>This topic describes migration actions for optional feature CIM.</p>
<h3 id="bookciminstall">CIM actions to perform before installing z/OS V2R1</h3><a id="idx783"></a>
<p>This topic describes CIM migration actions that you can perform
on your current (old) system. You do not need the z/OS V2R1 level
of code to make these changes, and the changes do not require the
z/OS V2R1 level of code to run once they are made.</p>
<p>None.</p>
<h3 id="cimbeforeipl">CIM actions to perform before the first IPL of z/OS V2R1</h3>
<p>This topic describes CIM migration actions that you can perform
after you have installed z/OS V2R1 but before the first time you IPL.
These actions might require the z/OS V2R1
level of code to be installed but do not require it to be active.</p>
<p>None.</p>
<h3 id="cimbafteripl">CIM actions to perform after the first IPL of z/OS V1R13</h3>
<p>This topic describes CIM migration actions that you can perform
only after you have IPLed z/OS V2R1. You need a running z/OS V2R1
system to perform these actions.</p>
<p><a href="e0z3m100.htm#javacpm">Update Capacity Provisioning Manager parameters to use CIM
Client for Java Version 2</a></p>
<h4 id="javacpm">Update Capacity Provisioning Manager parameters to use CIM
Client for Java Version 2</h4>
<p>[[[[ Contributing writer: Wolf-Dieter
Hahn/Germany/IBM@IBMDE ]]]] [[[[ Technical contact: Michael Groetzner/Germany/IBM@IBMDE
]]]]</p>
<p><strong>Description</strong>: If you set up your Provisioning Manager in
z/OS V1R11 or earlier, and you are not using the default installation
path /usr/lpp/wbem/jclient for your CIM component, you need
to set up the Capacity Provisioning Manager for the use of CIM Client
for Java Version 2.<a id="idx784"></a><a id="idx785"></a></p>
<p>z/OS V2R1 is planned to be the last release to include Version
1 of the Standards Based Linux Instrumentation for Manageability (SBLIM)
CIM client for Java. Version 1 support for the SourceForge open source
project was sunset in 2010. Version 2 of the SBLIM client, which is
designed to be a JSR48- compliant implementation, is included in z/OS
V1.13 and planned to be included in z/OS V2.1. IBM recommends that
users of SBLIM Version 1 convert to Version 2.</p>
<table id="wq416" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>CIM</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use Capacity Provisioning Manager
and are not using the default installation path for your CIM component.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:   
</p>
<ul>
<li>The Provisioning Manager user CPOSRV needs read access to CIM
Client for Java Version 2 sblim-cim-client2.jar. These access
rights are usually sufficient by default. If the current access rights
are insufficient, you must set the "other" read access permissions
of the file accordingly, using the UNIX command chmod, for example, <span class="synph"><span class="kwd">chmod
o+r /usr/lpp/wbem/jclient/sblim-cim-client2.jar</span></span>. Note
that this command must be issued by a user with appropriate <span>authorization</span>.</li>
<li>If your CIM installation directory is not at the default location,
you need to add the location of the CIM Client for Java Version 2 sblim-cim-client2.jar to
the CLASSPATH entry. If you have already specified the location of
a previous version of the CIM Client for Java, you need to add the
location of CIM Client for Java Version 2 before the location of the
previous version of CIM Client for Java. The CLASSPATH is specified
in the ENV member of the Provisioning Manager runtime environment
data set, prefix.PARM.  The prefix for the data set name is the high-level
qualifier of the Capacity Provisioning Manager parameters data set
 and the name of the domain managed by the Capacity Provisioning Manager.
 For example, with the default values, the data set name would be
CPO.DOMAIN1.PARM.</li></ul>
<p><strong>Reference information</strong>: For additional information about
Setting up a Capacity Provisioning domain,  see <cite>z/OS MVS Capacity Provisioning User&amp;apos;s
Guide</cite></p>
<h2 id="ad1coms1">Communications Server migration actions</h2>
<p>This topic describes migration actions for base element Communications
Server.</p>
<h3 id="dt2mg591">Communications Server actions to perform before installing
z/OS V2R1</h3><a id="idx786"></a>
<p>This topic describes Communications Server migration actions that
you can perform on your current (old) system. You do not need the z/OS V2R1 level of code to make
these changes, and the changes do not require the z/OS V2R1 level of code to run once they are
made.</p>
<p><a href="e0z3m100.htm#conass">Configuration assistant: Migrate to the Configuration Assistant
for Communications Server in the z/OS Management Facility (z/OSMF)</a></p>
<p><a href="e0z3m100.htm#dt2mg326">IP Services: Ensure FTP is listed in the AUTHCMD and AUTHPGM
NAMES section of your IKJTSOxx member of SYS1.PARMLIB</a></p>
<p><a href="e0z3m100.htm#dvipsec">IP Services: Understand the change in the support provided
by the DVIPSEC parameter on the IPSEC statement in the TCP/IP profile</a></p>
<p><a href="e0z3m100.htm#ipfrag">IP Services: Be aware of IP Fragment attack type of the Intrusion
Detection Services (IDS) enhancements to monitor both IPv4 and IPv6
traffic</a></p>
<p><a href="e0z3m100.htm#dt2mg327">IP Services: Plan for the change of greater than 8 characters
for the FTP password</a></p>
<p><a href="e0z3m100.htm#dt2mg328">IP Services: Relink NMI applications using the 64-bit TMI copy
buffer function (EZBTMIC4)</a></p>
<p><a href="e0z3m100.htm#dt2mg329">IP Services: Review C/C++ applications that use the GetProfile
request of the TCP/IP callable network management interface (NMI)</a></p>
<p><a href="e0z3m100.htm#preparefortheadditionofipv6supportforpolicy-basedrouting">IP Services: Prepare for the addition of IPv6 support for policy-based
routing</a></p>
<p><a href="e0z3m100.htm#dt2mg330">IP Services: Replace any GATEWAY statements in the TCP/IP profile
 with equivalent  BEGINROUTES statements</a></p>
<p><a href="e0z3m100.htm#snmpsys">IP Services: Remove customization of SNMP sysObjectID MIB object
in OSNMPD.DATA file**** DISCUSSION ABOUT REMOVING***************</a></p>
<p><a href="e0z3m100.htm#ftpdaemon">IP Services: Accommodate new format of FTP daemon console messages
that no longer are prefixed with '+'</a></p>
<p><a href="e0z3m100.htm#defidresolve">IP Services: Define a user ID for the system resolver with
an associated OMVS segment</a></p>
<p><a href="e0z3m100.htm#meestorg">IP Services: Ensure storage availability for ancillary input
queue for Enterprise Extender traffic</a></p>
<p><a href="e0z3m100.htm#ipfips">IP Services: Permit IKE daemon running in FIPS mode to use
additional ICSF services</a></p>
<p><a href="e0z3m100.htm#commsids">IP Services: Understand and prepare for expanded Intrusion
Detection Services</a></p>
<p><a href="e0z3m100.htm#ftchkpwd">IP Services: Ensure that the FTP user exit routine FTCHKPWD
tolerates an additional parameter</a></p>
<p><a href="e0z3m100.htm#portrnge">IP Services: Understand change in VIPARANGE security
verification processing</a></p>
<p><a href="e0z3m100.htm#dt2mg626">IP Services: Remove references to DSPNAME for TCP/IP dataspace
from DUMP and SLIP commands</a></p>
<p><a href="e0z3m100.htm#dt2mg627">IP Services: Move references to SEGMENTATIONOFFLOAD and NOSEGMENTATIONOFFLOAD
parameters from GLOBALCONFIG to IPCONFIG and IPCONFIG6 statement for
segmentation offload support</a></p>
<p><a href="e0z3m100.htm#bind2">IP Services: Migrate from BIND 9.2.0</a></p>
<p><a href="e0z3m100.htm#asgnbuf">SNA Services: Ensure IVTCSM ASSIGN_BUFFER requests
do not exceed 500 images for a single CSM buffer</a></p>
<p><a href="e0z3m100.htm#dt2mg629">SNA Services: Remove references to DSPNAME for VTAM dataspace
from DUMP and SLIP commands</a></p>
<h4 id="dt2mg604">Configuration assistant: Migrate to the Configuration Assistant
for Communications Server in the z/OS Management Facility (z/OSMF)</h4><a id="idx787"></a><a id="idx788"></a><a id="idx789"></a>
<p>Starting in z/OS V2R1, IBM Configuration Assistant for z/OS Communications
Server is no longer offered as a stand-alone application that runs
on the Windows operating system. IBM Configuration Assistant for z/OS
Communications Server is available as a fully supported task in the
z/OSMF product. Use the task available in z/OSMF.</p>
<table id="wq417" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if a Windows desktop version is being used.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<p>To use the IBM Configuration Assistant for z/OS Communications
Server task, you need to take the following steps:</p>
<ol type="1">
<li>Configure z/OSMF.</li>
<li>Transfer your existing backing store files into the z/OSMF environment
if desired.</li></ol>
<p><strong>Reference information</strong>: 
</p>
<ul>
<li>For information about configuring z/OSMF, see <cite>IBM z/OS Management Facility Configuration Guide</cite>.</li>
<li>For information about transferring Configuration Assistant backing
store files to z/OSMF, see the Updating z/OS for the Configuration
Assistant plug-in section in <cite>IBM z/OS Management Facility Configuration Guide</cite>.</li>
<li>For a complete list of all the z/OS Communications Server
commands and programs that need to be added to the AUTHCMD NAMES and
AUTHPGM NAMES statements in your IKJTSOxx PARMLIB member, see the <cite>z/OS Program Directory</cite> .</li></ul>
<h4 id="dt2mg605">IP Services: Ensure FTP is listed in the AUTHCMD and AUTHPGM
NAMES section of your IKJTSOxx member of SYS1.PARMLIB</h4><a id="idx790"></a>
<p></p>
<p><strong>Description</strong>: Beginning
in z/OS V2R1, the z/OS FTP client supports user exits. The FTP client
invokes z/OS Dynamic Exit Services (DES) to determine whether you
have installed FTP client user exit EZAFCCMD or EZAFCREP.  To invoke
DES successfully, the program FTP must be APF authorized. Therefore,
you must add  FTP to the AUTHCMD and AUTHPGM NAMES section of your
IKJTSOxx member of SYS1.PARMLIB.  Otherwise, the following error messages
EZA1555I are displayed when you start the FTP client:
</p>
<ul>
<li>CSVDYNEX DEFINE failed for user exit EZAFCCMD, RETURN CODE x'08'
REASON CODE x'00000804'</li>
<li>CSVDYNEX DEFINE failed for user exit EZAFCREP, RETURN CODE x'08'
REASON CODE x'00000804'</li></ul>
<table id="wq419" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td width="49%"><strong>Element or feature:</strong></td>
<td width="50%">Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes,
if you invoke the z/OS FTP client.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Add
FTP in the AUTHCMD and AUTHPGM NAMES section of your IKJTSOxx member
of SYS1.PARMLIB.</p>
<div>
<div class="note-noindent" id="wq420">
<span class="notetitle">Note:</span> <span class="notebody">In z/OS V2R1, SYS1.SAMPLIB(IKJTSO00) member contains
the FTP definitions in both AUTHCMD and AUTHPGM NAMES section.</span></div></div>
<p><strong>Reference information:</strong> 
</p>
<ul>
<li>FTP client user exits in <cite>z/OS Communications Server: IP Configuration Reference</cite>.</li>
<li>TSO command authorization in <cite>z/OS Communications Server: IP Configuration Guide</cite>..</li></ul>
<h4 id="dt2mg606">IP Services: Understand the change in the support provided
by the DVIPSEC parameter on the IPSEC statement in the TCP/IP profile</h4>
<p>[[[[ Contributing writer: Jie Z Zhu/China/IBM]]]]
[[[[ Technical contact: Brad Crater, Charles Cruse/Raleigh/IBM, Alan
Packett/Raleigh/IBM, Joyce Anne Porter/Raleigh/IBM&gt; ]]]]</p>
<p><strong>Description</strong>: Before z/OS V2R1, the DVIPSEC parameter on
the IPSEC statement in the TCP/IP profile enabled Sysplex-Wide Security
Associations (SWSA) for IPv4 on a stack that had IPCONFIG IPSECURITY
specified in the TCP/IP profile.  Support for SWSA for IPv6 was not
provided in these releases.</p>
<p>Beginning with z/OS V2R1, SWSA for IPv6 is supported.  The DVIPSEC
parameter on the IPSEC statement in the TCP/IP profile enables SWSA
for IPv6 on a stack that has IPCONFIG6 IPSECURITY specified in the
TCP/IP profile.</p>
<table id="wq421" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx791"></a><a id="idx792"></a><a id="idx793"></a><strong>Element
or feature</strong>:</td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the TCP/IP profile for your stack specifies
the IPSECURITY parameter on the IPCONFIG6 statement and also specifies
the DVIPSEC parameter on the IPSEC statement.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ul>
<li>If you have both of the following specified in your TCP/IP
profile, be aware that SWSA for IPv6 will be enabled on your stack: 

<ul>
<li>The IPSECURITY parameter on the IPCONFIG6 statement</li>
<li>The DVIPSEC parameter on the IPSEC statement</li></ul></li>
<li>If you have IPv6 TCP traffic that is protected by an IPSec Security
Association (SA) with an IPv6 DVIPA endpoint, you can see the following
changes: 

<ul>
<li>When an IPv6 DVIPA is moved during a planned or unplanned DVIPA
takeover, new SAs are automatically reestablished with the same security
service characteristics as the SAs that existed on the host that owned
the DVIPA.</li>
<li>IPv6 TCP traffic that is protected by an IPSec SA with a sysplex-distributed
DVIPA endpoint can be distributed to target hosts.</li></ul></li>
<li>Ensure that you configure the appropriate IP security policy on
the backup and target hosts.</li></ul>
<p><strong>Reference information</strong>: See "Sysplex-Wide Security Associations"
in <cite>z/OS Communications Server: IP Configuration Guide</cite>.</p>
<h4 id="dt2mg607">IP Services: Be aware of IP Fragment attack type of the Intrusion
Detection Services (IDS) enhancements to monitor both IPv4 and IPv6
traffic</h4><a id="idx794"></a><a id="idx795"></a><a id="idx796"></a>
<p>Beginning in z/OS V2R1, IP Fragment attack type of the Intrusion
Detection Services (IDS) is enhanced to monitor both IPv4 and IPv6
traffic for suspicious fragments. It is also enhanced further to check
for overlays that change the data in the packet. <span>Be aware
that in z/OS V2R1, if you have the IP fragment IDS attack enabled,
IPv6 traffic will now be monitored. In earlier releases, only IPv4
traffic was monitored.</span></p>
<table id="wq422" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are using IDS on a stack and the
IP Fragment attack type is enabled.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<p>If you are using IDS on a stack and the IP Fragment attack type
is enabled, be aware of the following information:  
</p>
<ul>
<li>Both IPv4 and IPv6 traffic are monitored for suspicious fragments.</li>
<li>The IP Fragment attack type checking is enhanced to check for
overlays that change the data in the packet, including changes to
the length of the packet.</li></ul>
<p><strong>Reference information</strong>: For more information about IP fragments,
see "Attack of IDS policy definition considerations" in <cite>z/OS Communications Server: IP Configuration Guide</cite>.</p>
<h4 id="dt2mg608">IP Services: Plan for the change of greater than 8 characters
for the FTP password</h4><a id="idx797"></a>
<p>Writer: Jim Guilianelli Developer: Shigeki
Kimura</p>
<p><strong>Description</strong>: Before z/OS V1R13 an FTP password greater than
8 characters was truncated to 8 characters. Starting with V1R13 the
z/OS FTP server supports password phrases. This support passes the
provided password to the installation security product without any
truncation.</p>
<p> The lack of the truncation might cause the FTP server SAF call
to fail. By applying the PTF for APAR PM62213, FTP has been modified
to support a new server FTP.DATA statement called PASSPHRASE. It indicates
whether the FTP server supports logging into FTP with password phrases.
The parameters are:
</p>
<ul>
<li>TRUE:  The FTP server allows an FTP client to log into FTP with
a password phrase. This is the default.</li>
<li>FALSE: The FTP server does not allow an FTP client to log into
FTP with a password phrase.</li></ul><p class="indatacontent">To expect the same behavior as in earlier releases to z/OS V1R13,
you need to specify the FALSE explicitly.</p>
<table id="wq423" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications
Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes,
if you are not using passphrases and wish the existing behavior (prior
to z/OS V1R13) to remain.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td></td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Decide if you need Communications Server
to continue the truncation of passwords for FTP or not.  If you would
like no truncation and intend to use passphrases for FTP, then the
default is acceptable for you.  If you wish to override the default
value and have the z/OS FTP server truncate passwords longer than
8 characters, then override the default for PASSPHRASE in FTP.DATA.</p>
<p><strong>Reference information:</strong> 
See <cite>z/OS Communications Server: IP Configuration Reference</cite>.</p>
<h4 id="dt2mg609">IP Services: Relink NMI applications using the 64-bit TMI copy
buffer function (EZBTMIC4)</h4><a id="idx798"></a><a id="idx799"></a>
<p></p>
<p><strong>Description</strong>: Starting
with z/OS V2R1, the interface between the 64-bit TMI copy buffer function
(EZBTMIC4) and the TCP/IP stack is changed. Applications that use
the real-time TCP/IP network monitoring network management interface
(NMI) and statically link to this function must either relink or change
to dynamic linking or loading of the function.</p>
<table id="wq424" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your application statically links to
the 64-bit TMI copy buffer function (EZBTMIC4). No change is required
for applications that use the 32-bit TMI copy buffer function (EZBTMIC1)
or that dynamically link or load EZBTMIC4.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If
your application statically links to the 64-bit TMI copy buffer function
(EZBTMIC4), relink your application, or change your application to
dynamically link to the 64-bit TMI copy buffer function (EZBTMIC4).</p>
<p><strong>Reference information:</strong> See
"EZBTMIC1 or EZBTMIC4: Copy TCP/IP Management Interface Data Buffer"
in <cite>z/OS Communications Server: IP Programmer&amp;apos;s Guide and Reference.</cite></p>
<h4 id="dt2mg610">IP Services: Review C/C++ applications that use the GetProfile
request of the TCP/IP callable network management interface (NMI)</h4><a id="idx800"></a>
<p></p>
<p><strong>Description</strong>: 
In z/OS V2R1, the definitions of some of the IPv6 address fields returned
by the TCP/IP callable NMI GetProfile request, have changed. The definitions
for the following fields are corrected to specify a data type of in6_addr
instead of a character string in the C/C++ header file ezbnmmpc.h.
</p>
<ul>
<li>NMTP_V6CFDynXcfAddr</li>
<li>NMTP_IPA6Addr</li></ul><p class="indatacontent">If you have C/C++ applications that reference these fields, you
need to modify your application before recompiling it with the updated
C/C++ header file.</p>
<table id="wq425" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you plan on recompiling your application
with the updated C/C++ header file.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ol type="1">
<li>Review the references to the changed fields in your application
program.</li>
<li>If you have C/C++ applications that reference these fields, you
need to modify your application before recompiling it with the updated
C/C++ header file.</li></ol>
<p><strong>Reference information:</strong> 
For more information about the GetProfile request, see "TCP/IP callable
NMI (EZBNMIFR)" in <cite>z/OS Communications Server: IP Programmer&amp;apos;s Guide and Reference.</cite></p>
<h4 id="dt2mg611">IP Services: Prepare for the addition of IPv6 support for policy-based
routing</h4><a id="idx801"></a>
<p><strong>Description</strong>: As
of z/OS V2R1 policy-based routing is enhanced to route IPv6 traffic.
In earlier releases a policy-based routing rule that did not specify
the source and destination IP addresses only applied to IPv4 packets.
Starting in z/OS V2R1, that same policy-based routing rule applies
to both IPv4 and IPv6 packets.</p>
<table id="wq427" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes,
if you are using policy-based routing on a stack that is being run
as a dual-mode stack (IPv4 and IPv6).</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If you have a policy-based routing rule that
specifies neither source IP addresses nor destination IP addresses,
the rule will apply to both IPv4 and IPv6 packets. If you want the
rule to continue to apply to only IPv4 packets, modify the rule to
specify either a source or destination IP address of 0.0.0.0/0.</p>
<p><strong>Reference information:</strong> See the RoutingRule statement
in <cite>z/OS Communications Server: IP Configuration Reference.</cite></p>
<h4 id="dt2mg612">IP Services: Replace any GATEWAY statements in the TCP/IP profile
 with equivalent  BEGINROUTES statements</h4><a id="idx802"></a><a id="idx803"></a>
<p>[[[[ Contributing writer: Sonja Moore/Durham/Contr/IBM@IBMUS
]]]] [[[[ Original technical contact: Greg Callis/Raleigh/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: As of z/OS V2R1 support for the GATEWAY statement
in the TCP/IP profile is eliminated. The BEGINROUTES/ENDROUTES statement
block was introduced in z/OS V1R1 Communications Server and replaces
the GATEWAY profile statement for configuration of static routes.
 The GATEWAY statement has been stabilized since then, and has not
been updated to support enhancements such as IPv6 and replaceable
static routes. Additionally, the GATEWAY syntax is error prone.</p>
<table id="wq428" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td align="left">Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to take advantage of the
latest support offered by BEGIROUTES/ENDROUTES.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>ZOSMIGV2R1_CS_GATEWAY can help you determine
if you are using any GATEWAY statements in your TCP/IP profile.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Replace any GATEWAY statements in your TCP/IP
profile with the equivalent BEGINROUTES/ENDROUTES statement block.</p>
<p> In order to create BEGINROUTES statements from your existing specification,
you can use IPCS. Run the TCPIPCS PROFILE report on a dump of the
TCP/IP address space and static routes are presented as a BEGINROUTES/ENDROUTES
statement block, even if you coded them by using a GATEWAY statement. .
However, you will have to execute the commands to know with certainty
what changes to make.</p>
<p><strong>Reference information:</strong> 
</p>
<ul>
<li>See "Chapter 2: TCP/IP Profile and Configuration Statements" in <cite>z/OS Communications Server: IP Configuration Reference</cite></li>
<li>See "Chapter 6: PCS Subcommands for TCP/IP" in z/OS Communications Server: IP Diagnosis Guide</li></ul>
<h4 id="snmpsys">IP Services: Remove customization of SNMP sysObjectID MIB object
in OSNMPD.DATA file**** DISCUSSION ABOUT REMOVING***************</h4>
<p>[[[[ Contributing writer: James E Becker/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Kristine Adamson/Raleigh/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: The SNMP agent allows you to provide some initial
settings for a small set of MIB objects by using the OSNMPD.DATA file.
One of the objects for which an initial value can be provided is sysObjectID.0.
The sysObjectID.0 object is the vendor's authoritative identification
of the network management subsystem contained in the entity. That
is, it is intended to uniquely identify the SNMP agent. Changing this
value is not recommended and the ability to change it will be disabled
in a future release. As of z/OS V1R4,
warning message EZZ6317I is written to the syslog daemon if the object
is set by using the OSNMPD.DATA file. As of z/OS V1R8, message EZZ6317I is also written
to the console.</p>
<table id="wq429" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx804"></a><a id="idx805"></a><a id="idx806"></a><a id="idx807"></a><strong>Element or feature</strong>:</td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>Future removal of the ability to customize the
sysObjectID value was announced in the z/OS V1R4
time frame. Message EZZ6317I is written to the syslog daemon as of z/OS V1R4, and to both the syslog
daemon and console as of z/OS V1R8.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because the ability to customize
the sysObjectID value is planned to be removed in a future release.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td></td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Review the statements in your OSNMPD.DATA
configuration file. If this file contains a statement for the sysObjectID
object, remove the statement from the file.</p>
<p><strong>Reference information</strong>: For details about statements in the
OSNMPD.DATA configuration file, see the network management topic of <cite>z/OS Communications Server: IP Configuration Guide</cite>.</p>
<h4 id="ftpdaemon">IP Services: Accommodate new format of FTP daemon console messages
that no longer are prefixed with '+'</h4>
<p>[[[[ Contributing writer: Jie Z Zhu/China/IBM]]]]</p>
<p><strong>Description</strong>: Before V1R13, FTP daemon console messages were
prefixed with a '+' status indicator. Beginning in V1R13, these messages
are no longer prefixed with the '+' status indicator.</p>
<p><a id="idx808"></a><a id="idx809"></a><a id="idx810"></a></p>
<table id="wq430" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Communications Server</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have message automation that expects
to see the '+' character.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<p>Adjust your message automation to examine only the message ID and
text of console messages, and not to examine the status character.
The following FTP daemon console messages are affected: 
</p>
<ul>
<li>EZYFT59I</li>
<li>EZYFT70I</li>
<li>EZYFT72I</li>
<li>EZYFT80I</li>
<li>EZYFT81I</li>
<li>EZYFT82I</li>
<li>EZYFT83I</li>
<li>EZYFT84I</li>
<li>EZYFT86I</li>
<li>EZYFT89I</li>
<li>EZYFT90I</li>
<li>EZY2702I</li>
<li>EZY2706E</li>
<li>EZY2707E</li>
<li>EZY2714I</li></ul>
<p><strong>Tip</strong>: The system might insert a character,like "+"
or "*" preceding the message identifier. This character is not a part
of the message identifier. Do not add it to the msgid specification
in the MPFLSTxx parmlib member.</p>
<p><strong>Reference information</strong>: For messages sent to the MCS/SMCS
consoles, see <cite>z/OS MVS System Messages, Vol 1 (ABA-AOM)</cite>.</p>
<h4 id="defidresolve">IP Services: Define a user ID for the system resolver with
an associated OMVS segment</h4>
<p>[[[[ Contributing writer: Jie Z Zhu/China/IBM
]]]] [[[[ Technical contacts: Michael Gierlach/Raleigh/IBM@IBMUS,
Gus Kassimis/Raleigh/IBM@IBMUS, Arnie Hackett/Raleigh/IBM@IBMUS, Scott
C Moonen/Raleigh/IBM, Tony Amitrano Jr/Raleigh/IBM@IBMUS, Karen Barton/Raleigh/IBM
]]]]</p>
<p><strong>Description</strong>: Starting with z/OS V1R13, the system resolver
uses z/OS UNIX services in the resolver address space. Use of z/OS
UNIX services requires the resolver to have an OMVS segment associated
with its user ID. If you do not define a user ID for the resolver
with an associated OMVS segment, the resolver initialization will
fail and the TCP/IP stack initialization will not be able to complete
with message </p>
<pre class="xmp"><code>EZZ9315E TCP/IP WAITING FOR RESOLVER TO INITIALIZE.</code></pre><a id="idx811"></a>
<table id="wq431" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you do not have a user ID defined for
the system resolver that has an associated OMVS segment, which provides
access to z/OS UNIX services.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>If you do not define a user ID for the system
resolver that includes an OMVS segment, the resolver initialization
will fail and the initialization of all TCP/IP stacks will be delayed.
The following messages might be issued to describe the initialization
failure scenario:

<ul>
<li>IEF695I START RESOLVER WITH JOBNAME RESOLVER IS ASSIGNED TO USER
RESOLVER</li>
<li>IEF403I RESOLVER - STARTED - TIME=13.40.06</li>
<li>ICH408I JOB(RESOLVER) STEP(RESOLVER) CL(PROCESS ) OMVS SEGMENT
NOT DEFINED</li>
<li>EZZ9301E RESOLVER ENDED ABNORMALLY</li>
<li>IEF450I RESOLVER RESOLVER - ABEND=SEC6 U0000 REASON=0F01C008 TIME=13.40.07</li>
<li>IEF404I RESOLVER - ENDED - TIME=13.40.07</li></ul></td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>If you already have a user ID for the system resolver started
procedure, and you explicitly defined an OMVS segment for the ID,
or an OMVS segment was created automatically through the RACF automated
assignment of unique UNIX identities support or through default OMVS
segment support, no action is required.</li>
<li>If you already have a resolver user ID but it does not have an
OMVS segment, you must define an OMVS segment for the resolver user
ID.</li>
<li>If you do not have a resolver user ID, you must create one that
includes an OMVS segment.</li></ol>
<p>The following information is an excerpt of the SEZAINST(EZARACF)
sample job that you can use to define a user ID with an OMVS segment
and assign it to the system resolver started procedure. You might
need to modify the sample values that are specified in the commands
for your environment.  For example, the UID, Default Group, and Resolver
user ID values are sample values.  </p>
<pre class="xmp"><code>//*=========================== RESOLVER ===============================
//*====================================================================
//*====================================================================
//*
//* Create the userid and its OMVS Segment for the daemon and
//* add it to the STARTED Class which is activated in this job.
//*
//* If you chose not to use the RACF STARTED Class,
//* the entry should be placed in the started procedures table ICHRIN03.
//*
//RESOLVER EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
SETROPTS CLASSACT(STARTED)
SETROPTS RACLIST(STARTED)
SETROPTS GENERIC(STARTED)
ADDUSER RESOLVER DFLTGRP(OMVSGRP) OMVS(UID(42) HOME('/')) -
NOPASSWORD
RDEFINE STARTED RESOLVER.* STDATA(USER(RESOLVER))
SETROPTS RACLIST(STARTED) REFRESH
SETROPTS GENERIC(STARTED) REFRESH
//*</code></pre>
<p><strong>Reference information</strong>: For information about defining and
assigning a user ID for started procedures, see  in <cite>z/OS Security Server RACF Security Administrator&amp;apos;s Guide</cite>.</p>
<p> For information about defining an OMVS segment, see  in <cite>z/OS Security Server RACF Security Administrator&amp;apos;s Guide</cite>.</p>
<p>For general information about the system resolver, see  in <cite>z/OS Communications Server: IP Configuration Guide</cite>.</p>
<h4 id="meestorg">IP Services: Ensure storage availability for ancillary input
queue for Enterprise Extender traffic</h4>
<p>[[[[ Contributing writer: Sonja Moore/Durham/Contr/IBM@IBMUS
]]]] [[[[ Technical contact: Bebe Isrel/Raleigh/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: In z/OS V1R13, the processing of IPAQENET and
IPAQENET6 INTERFACE statements is enhanced. Coding the WORKLOADQ parameter
on these INTERFACE statements now enables the QDIO inbound workload
queueing function for Enterprise Extender (EE) traffic. An additional
ancillary input queue (AIQ) is established for inbound traffic for
EE if HPR=RTP is specified as a VTAM start option. Each AIQ increases
storage utilization by an amount equal to 36K of fixed ECSA, plus
potentially the READSTORAGE value (64K multiplied by the number of
SBALs) of fixed CSM 4K data space storage. If you have configured
QDIO inbound workload queuing, you must ensure that there is sufficient
fixed ECSA and 4K CSM dataspace storage for the AIQ for EE traffic.</p>
<table id="wq433" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx812"></a><a id="idx813"></a><a id="idx814"></a><a id="idx815"></a><strong>Element or feature</strong>:</td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if you have the WORKLOADQ
parameter specified on the INTERFACE statement and you have concerns
about using additional storage.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>This migration action is required only if you
are using <span>OSA-Express3, or later,</span> features on an
IBM zEnterpsie z196.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>Each AIQ increases storage utilization by an
amount equal to 36K of fixed ECSA plus potentially the READSTORAGE
value (64K multiplied by the number of SBALs) of fixed CSM 4K data
space storage.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Verify if you are using EE; you are using EE if HPR=RTP
is defined as a VTAM start option and if an EE XCA Major Node is defined
and active. If you are using EE, continue with steps 2-5.  If you
have HPR=RTP defined as a VTAM start option but do not have an EE
XCA Major Node defined and active, continue with steps 2, 3 and 5.
 Otherwise there is no increase in storage usage and no further action
is required.</li>
<li>Count the <span>total number of OSA-Express3, and later,</span> interfaces
that are coded with the WORKLOADQ parameter on the IPAQENET and IPAQENET6
INTERFACE statements.  Make a note of the number.</li>
<li>Verify that sufficient ECSA is available. To do this, multiply
the <span>total number of OSA-Express3, and later,</span> interfaces
that have inbound workload queueing enabled (you determined this number
in step 2) by 36K. The resulting number indicates how much new ECSA
is required. Use the DISPLAY CSM command to verify that sufficient
ECSA is available to enable this function.</li>
<li>Verify that sufficient real storage is available. 64-bit real
storage is used for the dataspace read buffers. Multiply the <span>total
number of OSA-Express3, and later,</span> interfaces that have inbound
workload queueing enabled (determined in step 2) by <span>64K
and by 126 (8064K)</span>. The maximum number of read buffers per queue
is 126. The resulting number is approximately the amount of additional
64-bit real storage that is required for the data space read buffers
for all the new EE input queues.</li>
<li>If sufficient storage is not available, either increase the available
storage or consider defining some of the <span>OSA-Express3,
and later,</span> INTERFACE statements with the NOWORKLOADQ parameter.</li></ol>
<p><strong>Reference information</strong>:   in <cite>z/OS Communications Server: New Function Summary</cite></p>
<h4 id="ipfips">IP Services: Permit IKE daemon running in FIPS mode to use
additional ICSF services</h4>
<p>[[[[ Contributing writer: Sonja Moore/Durham/Contr/IBM@IBMUS
]]]] [[[[ Technical contact: Patrick LiVecchi/Raleigh/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: In z/OS V1R13, the Internet Key Exchange (IKE)
daemon is enhanced to take advantage of new services that are provided
by Integrated Cryptographic Service Facility (ICSF) when the IKE daemon
is running in Federal Information Processing Standards (FIPS) mode.
 The new ICSF services are provided in updates to ICSF PKCS number
11 functions CSFPDVK and CSFPDMK.  ICSF now provides the following
information to the IKE daemon, each with a single call to ICSF: 
</p>
<ul>
<li>The derivation of the original seed key.</li>
<li>The phase 1 key set.</li>
<li>The phase 2 key set.</li></ul>
<table id="wq435" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx816"></a><a id="idx817"></a><a id="idx818"></a><a id="idx819"></a><strong>Element or feature</strong>:</td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you currently run the IKE daemon in
FIPS mode and if you control the access to ICSF resources in the CSFSERV
class.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ul>
<li>The IKE daemon now requires READ access to the CSF1DVK and CSF1DMK
resources in CSFSERV when the IKE daemon is configured to run in FIPS
mode.</li>
<li>If your security server is RACF, issue the following commands
in the order shown.  If you use a different security server, determine
and perform the equivalent steps. 

<ol type="1">
<li>PERMIT CSF1DVK CLASS(CSFSERV) ID(IKED) ACCESS(READ)</li>
<li>PERMIT CSF1DMK CLASS(CSFSERV) ID(IKED) ACCESS(READ)</li>
<li>SETROPTS RACLIST(CSFSERV) REFRESH</li></ol></li></ul>
<p><strong>Reference information</strong>: For details, see the  in <cite>z/OS Communications Server: IP Configuration Guide</cite>.</p>
<h4 id="commsids">IP Services: Understand and prepare for expanded Intrusion
Detection Services</h4>
<p>[[[[ Contributing writer: Sonja Moore/Durham/Contr/IBM@IBMUS
]]]] [[[[ Technical contact: Joyce Anne Porter/Raleigh/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Beginning in z/OS V1R13, Intrusion Detection
Services (IDS) is enhanced to monitor IPv6 traffic. This includes
scan detection and reporting, attack detection, attack reporting,
attack prevention, and traffic regulation.  Additional attack detection,
reporting, and prevention are also provided for IPv4 traffic.</p>
<table id="wq437" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx820"></a><a id="idx821"></a><a id="idx822"></a><a id="idx823"></a><strong>Element
or feature</strong>:</td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are using IDS on a stack that is
being run as a dual-mode stack (IPv4 and IPv6).</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>If any of the following IDS attack types are enabled, be aware
that both IPv4 and IPv6 traffic will be monitored for attacks of these
types: 

<ul>
<li>Malformed attack type</li>
<li>UDP perpetual echo attack type</li>
<li>Flood attack type</li>
<li>ICMP redirect attack type</li></ul></li>
<li>If you use the <span class="synph"><span class="kwd">trmdstat</span></span> command to get
a consolidated view of IDS log records, be aware that the default
report, provided when the <span class="synph"><span class="kwd">trmdstat</span></span> command
is issued with no report option, will be the IDS Summary report. 
The IDS Summary report provides a summary of all IDS information.</li>
<li>If you have a TCP scan rule that applies to all local IP addresses
(such as when the LocalHostAddr All is specified explicitly or by
default in the policy), then TCP scan events will be detected for
both IPv4 and IPv6 packets. If you want the TCP scan rule to continue
to only detect scan events for IPv4 packets, modify the rule to specify
a local IP address of 0.0.0.0/0.</li>
<li>If you have a UDP scan rule that applies to all local IP addresses
(such as when the LocalHostAddr All is specified explicitly or by
default in the policy), then UDP scan events will be detected for
both IPv4 and IPv6 packets.  If you want the UDP scan rule to continue
to only detect scan events for IPv4 packets, modify the rule to specify
a local IP address of 0.0.0.0/0.</li>
<li>If you have a TCP traffic regulation (TR) rule that applies to
all local IP addresses (such as when the LocalHostAddr All is specified
explicitly or by default in the policy), then limits will be enforced
for both IPv4 and IPv6 connection requests.  If you want the TCP TR
rule to continue to only enforce limits for IPv4 connection requests,
modify the rule to specify a local IP address of 0.0.0.0/0.</li>
<li>If you have a UDP TR rule that applies to all local IP addresses
(such as when the LocalHostAddr All is specified explicitly or by
default in the policy), then limits will be enforced for both IPv4
and IPv6 packets.  If you want the UDP TR rule to continue to only
enforce limits for IPv4 packets, modify the rule to specify a local
IP address of 0.0.0.0/0.</li>
<li>If you use LDAP to configure IDS policy and you are using the
default value for attribute ibm-idsLocalHostIPAddress with a TCP scan,
UDP scan, TCP TR, or UDP TR rule, events will be detected and limits
will be enforced for both IPv4 and IPv6 traffic.  If you want these
rules to continue to apply to only IPv4 traffic, modify the attribute
to specify ibm-idsLocalHostIPAddress:3-0.0.0.0-0.</li></ol>
<p><strong>Reference information</strong>: For details, see the following: 
</p>
<ul>
<li>  in <cite>z/OS Communications Server: IP Configuration Guide</cite></li>
<li>IBM Configuration Assistant
for z/OS Communications Server
online help; see the What's New in V1R13 help information for IDS
configuration</li>
<li> in  <cite>z/OS Communications Server: IP Configuration Reference</cite></li></ul>
<h4 id="ftchkpwd">IP Services: Ensure that the FTP user exit routine FTCHKPWD
tolerates an additional parameter</h4><a id="idx824"></a><a id="idx825"></a>
<p>[[[[ Contributing writer: Sonja Moore/Durham/Contr/IBM@IBMUS
]]]] [[[[ Technical contacts: Gwen Adams/Raleigh/IBM@IBMUS, Janet
Wolf/Raleigh/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Starting in z/OS V1R13, the z/OS FTP server
is enhanced to allow logging into FTP with a password phrase. An additional
parameter describing the password or password phrase that is used
to log into the z/OS FTP server is now passed to the FTCHKPWD user
exit. <span>If you have installed an FTCHKPWD exit routine,
and your exit routine meets one or both criteria listed in <strong>Is the
migration action required?</strong> below, then you must take action.</span></p>
<table id="wq439" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx826"></a><a id="idx827"></a><a id="idx828"></a><a id="idx829"></a><strong>Element or feature</strong>:</td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your installation uses the FTCHKPWD
user exit routine, and if one of the following conditions is true: 

<ul>
<li>Your exit routine cannot tolerate an additional parameter passed
to the exit routine.</li>
<li>Your exit routine inspects or processes the password parameter
in any way.</li></ul></td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ul>
<li>Inspect your FTCHKPWD user exit routine.  Modify as needed to
support the additional parameter.</li></ul>
<p><strong>Reference information</strong>: For details, see the following: 
</p>
<ul>
<li> in <cite>z/OS Communications Server: IP Configuration Guide</cite>.</li>
<li> in <cite>z/OS Communications Server: IP Configuration Reference</cite>.</li></ul>
<h4 id="portrnge">IP Services: Understand change in VIPARANGE security
verification processing</h4>
<p>[[[[ Contributing writer: Jeffrey Gates/Durham/Contr/IBM@IBMUS
]]]] [[[[ Technical contacts: Andrew Arrowood/Raleigh/IBM@IBMUS, Sue
Huang/Raleigh/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Prior to z/OS V1R13, the System Authorization
Facility (SAF) resource profile associated with the VIPARANGE statement
(EZB.BINDDVIPARANGE.<span class="synph"><span class="var">sysname</span></span>.<span class="synph"><span class="var">tcpname</span></span>)
was ignored in the following scenario when an application issues a
bind: <a id="idx830"></a></p>
<ul>
<li>The port specified on the bind matches a PORT statement, and</li>
<li>the IP address of the application's bind is within a VIPARANGE
subnet, or the application's bind is an unspecified address and the
IP address on the BIND parameter of the PORT statement is within a
VIPARANGE subnet.</li></ul>
<p>In this scenario, the PORT statement (including its optional SAF
parameter) was used to control access to both the port and to creating
the dynamic VIPA (DVIPA).</p>
<p>Beginning in V1R13, the VIPARANGE resource profile is
not ignored in this scenario; creation of the IP address is controlled
by both the SAF resource profile associated with the VIPARANGE statement
and by the PORT statement:</p>
<ul>
<li>For a VIPARANGE statement, you can control the creation of the
IP address by defining the following SAF resource profiles in the
SERVAUTH class: 

<ul>
<li>EZB.BINDDVIPARANGE.<span class="synph"><span class="var">sysname</span></span>.<span class="synph"><span class="var">tcpname</span></span></li>
<li>EZB.BINDDVIPARANGE.<span class="synph"><span class="var">sysname</span></span>.<span class="synph"><span class="var">tcpname</span></span>.<span class="synph"><span class="var">resname</span></span>,
if the new SAF parameter is included on the VIPARANGE statement</li></ul></li>
<li>The PORT statement controls whether an application can
bind to a given port.</li></ul>
<table id="wq440" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have defined the EZB.BINDDVIPARANGE.<span class="synph"><span class="var">sysname</span></span>.<span class="synph"><span class="var">tcpname</span></span> resource
profile, but you have not given READ access to this resource to all
applications that create DVIPAs by binding to addresses that are within
a VIPARANGE subnet.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Be aware that the EZB.BINDDVIPARANGE.<span class="synph"><span class="var">sysname.tcpname</span></span> resource
profile is always checked if defined; ensure all applications that
create DVIPAs by binding to addresses within a VIPARANGE subnet have
READ access to this resource.</p>
<p><strong>Reference information</strong>: For details, see the following: 
</p>
<ul>
<li> in <cite>z/OS Communications Server: New Function Summary</cite></li>
<li> in <cite>z/OS Communications Server: IP Configuration Guide</cite></li>
<li> in <cite>z/OS Communications Server: IP Configuration Guide</cite></li>
<li> in <cite>z/OS Communications Server: IP Configuration Reference</cite></li></ul>
<h4 id="dt2mg626">IP Services: Remove references to DSPNAME for TCP/IP dataspace
from DUMP and SLIP commands</h4><a id="idx831"></a>
<p></p>
<p><strong>Description</strong>: Starting with z/OS V1R13, the TCP/IP dataspace
is relocated from ECSA to HVCOMMON and the TCP/IP dataspace is eliminated.</p>
<table id="wq441" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS
Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes,
if you have references to DSPNAME for TCP/IP dataspace from DUMP and
SLIP commands.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ul>
<li>Accommodate the change in z/OS V1R13, to the value of the SIZE
parameter of the TRACE start option and the MODIFY TRACE command,
which specifies the number of megabytes of HVCOMMON (for example,
SIZE=4M).</li>
<li>Specify&nbsp;a&nbsp;larger&nbsp;buffer&nbsp;size&nbsp;for&nbsp;the&nbsp;CTRACE&nbsp;component&nbsp;SYSTCPIP.&nbsp;Code&nbsp;the&nbsp;TRACE&nbsp;CT&nbsp;command
and specify a value up to 1024 megabytes (1024M)&nbsp;for&nbsp;the&nbsp;SYS1.PARMLIB&nbsp;member&nbsp;CTIEZBxx&nbsp;or&nbsp;use&nbsp;the&nbsp;command&nbsp;TRACE
CT,nnnM,COMP=SYSTCPIP,SUB=(procedure_jobname).</li>
<li>In any automation programs, accommodate the numerous messages
that are no longer issued and are retired.</li></ul>
<p><strong>Reference information</strong>: None.</p>
<h4 id="dt2mg627">IP Services: Move references to SEGMENTATIONOFFLOAD and NOSEGMENTATIONOFFLOAD
parameters from GLOBALCONFIG to IPCONFIG and IPCONFIG6 statement for
segmentation offload support</h4><a id="idx832"></a>
<p></p>
<p><strong>Description</strong>: Starting in z/OS V1R13, the SEGMENTATIONOFFLOAD
and NOSEGMENTATIONOFFLOAD parameters on the GLOBALCONFIG statement
are deprecated. If no actions are taken to move these parameters to
the IPCONFIG and IPCONFIG6 statements, an informational message EZZ0758I
is issued to the console to indicate that the parameters will be retired
in a future release.</p>
<table id="wq442" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS
Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes,
if you have SEGMENTATIONOFFLOAD and NOSEGMENTATIONOFFLOAD parameters
on the GLOBALCONFIG statement.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  Remove any instance of  the SEGMENTATIONOFFLOAD
and NOSEGMENTATIONOFFLOAD parameters on the GLOBALCONFIG statement.</p>
<p><strong>Reference information</strong>: For more information, see <cite>z/OS Summary of Message and Interface Changes</cite>.</p>
<h4 id="dt2mg628">IP Services: Migrate from BIND 9.2.0</h4>
<p>[[[[ Contributing writer: Jie Z Zhu/China/IBM]]]]
[[[[ Technical contact: Andy Tracy/Raleigh/IBM, Joshua Bennetone/Durham/IBM&gt;
]]]]</p>
<p><strong>Description</strong>: z/OS V1R13 was the last release that supported
the z/OS BIND 9.2.0 name server function. If you are using this function
as a name server, you must find a replacement.</p>
<table id="wq443" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx833"></a><a id="idx834"></a><a id="idx835"></a><strong>Element or feature</strong>:</td>
<td>Communications Server</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>The removal of the BIND 9.2.0 function was first
announced in February 2009. z/OS V1R13 was the last release that supported
the z/OS BIND 9.2.0 name server function, as stated in the z/OS V1R13
preview announcement on February 11th, 2011.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are using the BIND 9.2.0 function
as a name server.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ul>
<li>If you are using z/OS BIND 9.2.0 as a caching-only name server,
use the z/OS resolver DNS caching function to cache DNS responses.</li>
<li>If you are using z/OS BIND 9.2.0 as a primary or secondary authoritative
name server, investigate using BIND on Linux for System z or BIND
on an IBM blade in a zBX.</li>
<li>Update the NSINTERADDR statements in the resolver configuration
file.</li>
<li>If the z/OS BIND 9.2.0 name server is the only name server to
be contacted in the NSINTERADDR list of name servers, replace the
name server entry with one or more name server IP addresses.</li>
<li>If more than one name server is in the NSINTERADDR list of name
servers, delete the IP address of the z/OS BIND 9.2.0 name server.</li>
<li>If the automated domain name registration(ADNR) application is
being used, ensure the name server is configured to support ADNR.
 See <cite>z/OS Communications Server: IP Configuration Guide</cite> for
configuring automated domain name registration.</li></ul>
<p><strong>Reference information</strong>: For details about the resolver, see <cite>z/OS Communications Server: IP Configuration Guide</cite> and <cite>z/OS Communications Server: IP Configuration Reference</cite>.</p>
<h4 id="asgnbuf">SNA Services: Ensure IVTCSM ASSIGN_BUFFER requests
do not exceed 500 images for a single CSM buffer</h4>
<p>[[[[ Contributing writer: Sonja Moore/Durham/Contr/IBM@IBMUS
]]]] [[[[ Technical contact: Harish Shah/Raleigh/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Beginning with z/OS V1R13, Communications
Storage Manager (CSM) will reject the ASSIGN_BUFFER request after
500 image buffers of a single CSM buffer are requested, and CSM will
return a new reason code of 26.<span> The new reason code 26
states: "Assign buffer request failed because CSM reached the limit
of the maximum number of image buffers of the single CSM buffer."</span></p>
<table id="wq444" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx836"></a><a id="idx837"></a><a id="idx838"></a><a id="idx839"></a><strong>Element or feature</strong>:</td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended. Your application probably
does not request more than 500 images of a CSM buffer; however, you
should examine IVTCSM ASSIGN_BUFFER calls to ensure that this is the
case.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: <span>To prevent application failures
due to excessive ASSIGN_BUFFER requests</span>: 
</p>
<ul>
<li>Identify any authorized applications that use CSM services and
verify that the number of image buffers requested by IVTCSM ASSIGN_BUFFER
for a single CSM buffer can never be more than 500.</li>
<li>If necessary, change the application so the total number
of IVTCSM ASSIGN_BUFFER image buffer requests is 500 or less.</li></ul>
<p><strong>Reference information</strong>: None.</p>
<h4 id="dt2mg629">SNA Services: Remove references to DSPNAME for VTAM dataspace
from DUMP and SLIP commands</h4><a id="idx840"></a>
<p></p>
<p><strong>Description</strong>: Starting with z/OS V1R13, the VTAM dataspace
is relocated from ECSA to HVCOMMON and the VTAM data space is eliminated.</p>
<table id="wq445" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS
Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
installing z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes,
if you have references to DSPNAME for TCP/IP dataspace from DUMP and
SLIP commands.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ul>
<li>Accommodate the change in z/OS V1R13, to the value of the SIZE
parameter of the TRACE start option and the MODIFY TRACE command,
which specifies the number of megabytes of HVCOMMON (for example,
SIZE=4M).</li>
<li>Remove any instance of the DSPSIZE parameter because it is not
valid.</li>
<li>In any automation programs, accommodate the numerous messages
that are no longer issued and are retired.</li></ul>
<p><strong>Reference information</strong>: None.</p>
<h3 id="e0z3m100-gen103">Communications Server actions to perform before the first IPL
of z/OS V2R1</h3>
<p>This topic describes Communications Server migration actions that
you can perform after you have installed z/OS V2R1 but before the first time you IPL.
These actions might require the z/OS V2R1
level of code to be installed but do not require it to be active.</p>
<p><a href="e0z3m100.htm#dt2mg340">IP Services: Remove ICLI component from z/OS</a></p>
<p><a href="e0z3m100.htm#dt2mg342">IP Services: If the NSS daemon is configured in FIPS 140 mode,
ensure ICSF is active before starting the daemon.</a></p>
<p><a href="e0z3m100.htm#dt2mg343">IP Services: If the IKE daemon is configured in FIPS 140 mode,
ensure ICSF is active before starting the daemon.</a></p>
<p><a href="e0z3m100.htm#dt2mg345">IP Services: Allow users of AT-TLS access to CSFIQA and CSFRNG
resources of the CSFSERV class if ICSF will be used with AT-TLS</a></p>
<p><a href="e0z3m100.htm#ipauto">IP Services: Update automation on D TCPIP,tnproc,&lt;Telnet&gt;,CONN
 for the expanded EN TY column in message EZZ6064I</a></p>
<p><a href="e0z3m100.htm#resolver">IP Services: Update automation to monitor resolver address
space initialization completion messages</a></p>
<p><a href="e0z3m100.htm#omroute">IP Services: Update OMPROUTE configuration procedures for OMPROUTE_OPTIONS</a></p>
<p><a href="e0z3m100.htm#dt2mg346">IP Services: Check the values specified for TCP related configuration
statements.</a></p>
<p><a href="e0z3m100.htm#dt2mg347">IP Services: Make changes for Netstat enhancements</a></p>
<p><a href="e0z3m100.htm#dt2mg345">IP Services: Allow users of AT-TLS access to CSFIQA and CSFRNG
resources of the CSFSERV class if ICSF will be used with AT-TLS</a></p>
<p><a href="e0z3m100.htm#upcsetc">IP Services: Update /etc configuration files</a></p>
<p><a href="e0z3m100.htm#viparange">IP Services: Review VIPARANGE definitions</a></p>
<p><a href="e0z3m100.htm#vitrelocate">SNA Services: Adjust to the relocation of the VTAM internal
trace table</a></p>
<h4 id="dt2mg632">IP Services: Remove ICLI component from z/OS</h4><a id="idx841"></a><a id="idx842"></a>
<p>[[[[ Contributing writer: Jim Guilianelli]]]]
[[[[ Original technical contact: Greg Callis/Raleigh/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: IBM intends to remove the Integrated Call Level
Interface (ICLI) in z/OS z/OS V2R1. ICLI is used by those who have
requested and obtained the ICLI API documentation and the C language
header file. IBM believes that users of this interface have changed
from using ICLI to standard IBM DB2 Connect for database connectivity
and do not need it when z/OS V2R1 becomes available. ICLI has not
been enhanced since z/OS 1.6. IBM intends to exclude ICLI from releases
after z/OS V1R13.</p>
<table id="wq446" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td align="left">Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended?</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>ZOSMIGV2R1_CS_GATEWAY can help you determine
if you are using any GATEWAY statements in your TCP/IP profile.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Reomve the ICLI component. To identify the
ICLI components examine the ibmicli.h header file?????????? Contact
your IBM representative if you have questions?</p>
<p><strong>Reference information:</strong> None.</p>
<h4 id="dt2mg633">IP Services: If the NSS daemon is configured in FIPS 140 mode,
ensure ICSF is active before starting the daemon.</h4><a id="idx843"></a>
<p></p>
<p><strong>Description</strong>: FIPS
140 support now requires ICSF services.  If the NSS daemon is configured
in FIPS 140 mode, the daemon will fail to activate if ICSF is not
active.  Ensure ICSF is started prior to starting the NSS daemon if
the NSS daemon is configured in FIPS 140 mode.</p>
<table id="wq447" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the NSS daemon is configured in FIPS
140 mode.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>ICSF.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If
the NSS daemon is configured in FIPS 140 mode, ensure ICSF is active
prior to starting the NSS daemon.</p>
<p><strong>Reference information:</strong> See &quot;Steps for preparing the z/OS
system for IP security&quot; and &quot;Steps for configuring IP security to
support FIPS 140 mode&quot; in "Chapter 19 IP Security" in <cite>z/OS Communications Server: IP Configuration Guide</cite>.</p>
<h4 id="dt2mg634">IP Services: If the IKE daemon is configured in FIPS 140 mode,
ensure ICSF is active before starting the daemon.</h4><a id="idx844"></a>
<p></p>
<p><strong>Description</strong>: FIPS
140 support now requires ICSF services.  If the IKE daemon is configured
in FIPS 140 mode, the daemon will fail to activate if ICSF is not
active.  Ensure ICSF is started prior to starting the IKE daemon if
the IKE daemon is configured in FIPS 140 mode.</p>
<table id="wq448" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the IKE daemon is configured in FIPS
140 mode.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>ICSF.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If
the IKE daemon is configured in FIPS 140 mode, ensure ICSF is active
prior to starting the IKE daemon.</p>
<p><strong>Reference information:</strong> See
&quot;Steps for preparing the z/OS system for IP security&quot; and &quot;Steps for
configuring IP security to support FIPS 140 mode&quot; in Chapter 19 IP
Security in <a href="./f1a2b300.html#f1a2b300">z/OS Communications Server: IP Configuration Guide</a>
for additional information.</p>
<h4 id="dt2mg635">IP Services: Allow users of AT-TLS access to CSFIQA and CSFRNG
resources of the CSFSERV class if ICSF will be used with AT-TLS</h4><a id="idx845"></a><a id="idx846"></a>
<p></p>
<p><strong>Description</strong>: Starting in z/OS V2R1, System SSL will attempt
to use ICSF services if ICSF is active during AT-TLS group initialization.
If ICSF is active and the CSFSERV class is active, the userid associated
with TCP/IP stack should have READ access to the CSFIQA and CSFRNG
resources of the CSFSERV class. This will allow System SSL to be aware
of the hardware available with ICSF and use ICSF to generate random
numbers during initialization. Application userids using AT-TLS groups
should also be given READ access to the CSFRNG resource of the CSFSERV
class.</p>
<table id="wq449" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:. 
</p>
<ol type="1">
<li>If the CSFSERV class is active, give READ access to the userid
associated with the TCP/IP stack and any application userid using
the TTLSGroup to the CSFRNG resource within the CSFSERV class.</li>
<li>If the CSFSERV class is active, give READ access to the userid
associated with the TCP/IP stack to the CSFIQA resource within the
CSFSERV class.</li></ol>
<p><strong>Reference information:</strong> See &quot;See Chapter 3. Using Cryptographic
Features with System SSL" in <cite>z/OS Cryptographic Services System SSL Programming</cite>.</p>
<h4 id="dt2mg636">IP Services: Update automation on D TCPIP,tnproc,&lt;Telnet&gt;,CONN
 for the expanded EN TY column in message EZZ6064I</h4><a id="idx847"></a><a id="idx848"></a><a id="idx849"></a>
<p><strong>Description</strong>: Message EZZ6064I, which is issued
in response to a D TCPIP,tnproc,&lt;Telnet&gt;,CONN command,  is expanded
by two bytes to show a four byte cipher value when the connection
is secured with AT-TLS.  As a result of this change, the previous
column header of "EN TY" has been changed to "ENCR TYPE"  The cipher
value can be up to four bytes in length. Cipher values less than four
bytes are padded with blanks.</p>
<table id="wq451" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Communications Server</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if automating on the  D TCPIP,tnproc,&lt;Telnet&gt;,CONN
command message EZZ6064I.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>The AT-TLS group configured with FIPS140-2 will
fail to initialize if ICSF is not active.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ul>
<li>Be aware of the changes in message EZZ6064I.</li>
<li>Update any automation on  D TCPIP,tnproc,&lt;Telnet&gt;,CONN 
message EZZ6064I.</li></ul>
<p><strong>Reference information</strong>: See an example of the updated "D
TCPIP,tnproc,&lt;Telnet&gt;,CONN output" in <cite>z/OS Communications Server: IP System Administrator&amp;apos;s Commands</cite>.</p>
<h4 id="resolver">IP Services: Update automation to monitor resolver address
space initialization completion messages</h4><a id="idx850"></a><a id="idx851"></a><a id="idx852"></a><a id="idx853"></a><a id="idx854"></a><a id="idx855"></a>
<p>[[[[ Contributing writer: Jie Z Zhu/China/IBM]]]]
[[[[ Technical contact: Michael Gierlach/Raleigh/IBM&gt; ]]]]</p>
<p><strong>Description</strong>: In releases before z/OS V2R1, the resolver
address space initialization failed if errors were detected in the
setup file. Beginning with z/OS V2R1, the resolver processes the entire
resolver setup file during resolver address space initialization.
When the resolver detects syntax errors or when it does not recognize
the resolver setup statement, the resolver ignores the setup file
statement and the resolver initialization completes successfully with
warning messages. Ignoring the setup file statement might result in
the resolver using default settings for some resolver setup statements
if the statement was specified with errors.</p>
<p>If the resolver issues warning messages during address space initialization,
the resolver issues message EZD2038I instead of message EZZ9293I when
the initialization completes.<a id="idx856"></a><a id="idx857"></a><a id="idx858"></a></p>
<table id="wq452" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Communications Server</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you customize the resolver and want
to correct any errors that the resolver finds in the resolver setup
file.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>The resolver might initialize with the incorrect
configuration because of errors in the setup file, which might cause
applications issuing resolver API calls to get erroneous results.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<p>If you customize the resolver and want to detect when
the resolver ignores errors in the resolver setup file during address
space initialization, do the following:  
</p>
<ul>
<li>Monitor resolver address space initialization for message
EZD2038I RESOLVER INITIALIZATION COMPLETED WITH WARNINGS.</li>
<li>Issue the MODIFY RESOLVER,DISPLAY command after system
initialization completed to determine if the following message has
been issued in the display output:  
<pre class="xmp"><code>EZD2039I WARNINGS ISSUED DURING RESOLVER INITIALIZATION</code></pre></li></ul><p class="indatacontent">If the resolver issues the message EZD2038I or EZD2039I, take
the following steps:</p>
<ol type="1">
<li>Collect the system console messages that are issued by the resolver
during resolver address space initialization.</li>
<li>Contact the system programmer. The system programmer needs to
use the resolver warning messages to correct the errors in the resolver
setup file.</li>
<li>When the errors are corrected, the network operator needs to issue
a MODIFY RESOLVER,REFRESH,SETUP=setup_file command to correct the
resolver configuration.</li></ol>
<p><strong>Reference information</strong>: For more information about the resolver,
see "Customizing the resolver" in <cite>z/OS Communications Server: IP Configuration Guide</cite>.</p>
<h4 id="dt2mg637">IP Services: Update OMPROUTE configuration procedures for OMPROUTE_OPTIONS</h4>
<p>[[[[ Contributing writer: Jie Z Zhu/China/IBM]]]]
[[[[ Technical contact: Jon Bell/Raleigh/IBM&gt; ]]]]</p>
<p><strong>Description</strong>: Before z/OS V2R1, the OMPROUTE_OPTIONS environment
variable was used by OMPROUTE to set various controls for OMPROUTE
processing and only the hello_hi option was supported. The hello_hi
option optimized the processing of OSPF Hello packets in OMPROUTE
 to minimize the potential adjacency failures with neighbors.</p>
<p>Beginning with z/OS V2R1, the OMPROUTE_OPTIONS environment
variable is ignored and will not be supported in a future release.
The optimization function for OSPF Hello packets is always enabled</p>
<p>If the environment variable, OMPROUTE_OPTIONS, is configured
then the following message will be issued to the console or hardcopy
log:</p>
<pre class="xmp"><code>EZZ8172I <em>jobname</em> IGNORING ENVIRONMENT VARIABLE OMPROUTE_OPTIONS WHICH WILL BE 
RETIRED IN A FUTURE RELEASE </code></pre>
<table id="wq454" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx859"></a><a id="idx860"></a><a id="idx861"></a><a id="idx862"></a><strong>Element
or feature</strong>:</td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if the environment variable
OMROUTE_OPTIONS=hello_hi is coded.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  If you want to suppress the warning
message that the environment variable OMPROUTE_OPTIONS is to be retired
in a future release, remove the environment variable from the OMPROUTE
environment variable file.</p>
<p><strong>Reference information</strong>:  See "Steps for Configuring
OMPROUTE" in <cite>z/OS Communications Server: IP Configuration Guide</cite>.</p>
<h4 id="dt2mg638">IP Services: Check the values specified for TCP related configuration
statements.</h4><a id="idx863"></a>
<p></p>
<p><strong>Description</strong>: As of z/OS V2R1 the default values
for TCPRCVBUFRSIZE and TCPSENDBUFRSIZE parameters on the TCPCONFIG
statement have been increased from 16K to 64K. Increasing the receive
or send buffer size does not in itself allocate or consume any additional
storage.  The receive and send buffer sizes determine the amount of
data that can be buffered by TCPIP for the application. The increase
in the default values can allow more data to be buffered and consequently,
more storage to be used.</p>
<p>The default value for the SOMAXCONN statement has increased from
10 to 1024. The SOMAXCONN value limits what a server application can
specify for its listening backlog.</p>
<p>The amount of time a connection remains in FINWAIT2 has been changed
to use the value specified on the TCPCONFIG parameter FINWAIT2. Previously,
an additional seventy five seconds was added to the time specified
on the FINWAIT2 parameter before the connection was dropped</p>
<table id="wq455" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
the first IPL of z/OS V2R1..</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes,
for one of the following conditions:

<ul>
<li>If the potential increase in the size of the send and receive
buffers is likely to cause a storage shortage</li>
<li>If you used the current defaulted value of SOMAXCONN to limit
applications from specifying a listening backlog larger than 10</li>
<li>If you require the additional seventy-five seconds before the
connection is dropped</li></ul></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  If needed, do the following:
</p>
<ul>
<li>Change the TCPRCVBUFRSIZE and TCPSENDBUFRSIZE values to 16K. C</li>
<li>Change the SOMAXCONN value to 10.</li>
<li>Increase the FINWAIT2 value by 75 seconds.</li></ul>
<p><strong>Reference information</strong>: See an example of the updated "D
TCPIP,tnproc,&lt;Telnet&gt;,CONN output" in <cite>z/OS Communications Server: IP Configuration Reference</cite>.</p>
<h4 id="dt2mg639">IP Services: Make changes for Netstat enhancements</h4><a id="idx864"></a><a id="idx865"></a>
<p>[[[[ Contributing writer: Sonja Moore/Durham/Contr/IBM@IBMUS
]]]] [[[[ Original technical contact: Greg Callis/Raleigh/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: The Netstat command displays the status of
a local host. Each release, the Netstat reports are changed in ways
that can affect automation or front-end programs.</p>
<table id="wq456" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td align="left">Before the first IPL of z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the changed or removed settings affect
either (1) automation that uses the Netstat report output or (2) front-end
programs that invoke the Netstat command.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None..</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Accommodate Netstat changes in your automation
and front-end programs. You can begin planning your changes by reviewing
the ways in which the displays are updated each release. For details
about how each Netstat report has changed, see z/OS Summary of Message
and Interface Changes. However, you will have to execute the commands
to know with certainty what changes to make.</p>
<p><strong>Reference information:</strong> 
</p>
<ul>
<li>For details about using Netstat, see z/OS Communications Server:
IP System Administrator's Commands. <cite>z/OS Communications Server: IP Configuration Reference</cite></li>
<li>For details about Netstat report changes, see z/OS Communications Server: IP Diagnosis Guide</li></ul>
<h4 id="dt2mg640">IP Services: Allow users of AT-TLS access to CSFIQA and CSFRNG
resources of the CSFSERV class if ICSF will be used with AT-TLS</h4><a id="idx866"></a><a id="idx867"></a>
<p></p>
<p><strong>Description</strong>: Starting in z/OS V2R1, System SSL will attempt
to use ICSF services if ICSF is active during AT-TLS group initialization.
If ICSF is active and the CSFSERV class is active, the userid associated
with TCP/IP stack should have READ access to the CSFIQA and CSFRNG
resources of the CSFSERV class. This will allow System SSL to be aware
of the hardware available with ICSF and use ICSF to generate random
numbers during initialization. Application userids using AT-TLS groups
should also be given READ access to the CSFRNG resource of the CSFSERV
class.</p>
<table id="wq457" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Communications Server</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:. 
</p>
<ol type="1">
<li>If the CSFSERV class is active, give READ access to the userid
associated with the TCP/IP stack and any application userid using
the TTLSGroup to the CSFRNG resource within the CSFSERV class.</li>
<li>If the CSFSERV class is active, give READ access to the userid
associated with the TCP/IP stack to the CSFIQA resource within the
CSFSERV class.</li></ol>
<p><strong>Reference information:</strong> See &quot;See Chapter 3. Using Cryptographic
Features with System SSL" in <cite>z/OS Cryptographic Services System SSL Programming</cite>.</p>
<h4 id="dt2mg641">IP Services: Update /etc configuration files</h4>
<p>[[[[ Technical contact: Kristine Adamson/Raleigh/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: Some utilities provided by Communications Server
require the use of certain configuration files. You are responsible
for providing these files if you expect to use the utilities. IBM provides default configuration
files as samples in the <samp class="xph">/usr/lpp/tcpip/samples</samp> directory.
Before the first use of any of these utilities, you should copy these
IBM-provided samples to the <samp class="xph">/etc</samp> directory (in most
cases). You can further customize these files to include installation-dependent
information. An example is setting up the <samp class="xph">/etc/osnmpd.data</samp> file
by copying the sample file from <samp class="xph">/usr/lpp/tcpip/samples/osnmpd.data</samp> to <samp class="xph">/etc/osnmpd.data</samp> and
then customizing it for the installation.</p>
<p>If you customized any of the configuration files that have changed,
then you must incorporate the customization into the new versions
of the configuration files.</p>
<table id="wq459" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>Various releases. See <a href="e0z3m100.htm#upcsetc__csetctb">Table 10</a>.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have customized a configuration
file (listed in <a href="e0z3m100.htm#upcsetc__csetctb">Table 10</a>) that IBM has changed.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  If you added installation-dependent customization
to any of the IBM-provided configuration files listed in <a href="e0z3m100.htm#upcsetc__csetctb">Table 10</a>, make the same changes in the new
versions of the files by copying the IBM-provided samples to the files
shown in the table and then customizing the files.</p>
<table id="dt2mg642" width="100%" summary="" border="1" frame="border" rules="all" class="presentation" role="presentation">
<caption><a href="e0z3m100.htm#FT_Table_13">Table 13. Changed Communications Server configuration files</a></caption>
<thead valign="bottom">
<tr>
<th id="wq460" width="19%" align="left" valign="bottom">Utility</th>
<th id="wq461" width="34%" align="left" valign="bottom">IBM-provided sample file</th>
<th id="wq462" width="15%" align="left" valign="bottom">Target location</th>
<th id="wq463" width="30%" align="left" valign="bottom">What changed and when</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left" valign="top" headers="wq460">SNMP agent</td>
<td align="left" valign="top" headers="wq461">/usr/lpp/tcpip/samples/osnmpd.data</td>
<td align="left" valign="top" headers="wq462">/etc/osnmpd.data</td>
<td align="left" valign="top" headers="wq463">Every release, the value of the sysName
MIB object is updated to the current release.</td>
</tr>
<tr>
<td align="left" headers="wq460">File Transfer Protocol Daemon
(FTPD)</td>
<td align="left" headers="wq461">SEZAINST(FTPSDATA)</td>
<td align="left" headers="wq462">/etc/ftp.data</td>
<td align="left" headers="wq463">In z/OS V2R1, a new configuration
statement is provided to specify that a type 119 SMF record of subtype
71 is collected for the FTP daemon configuration information when
the FTP daemon starts.</td>
</tr>
</tbody>
</table>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li>For more details about configuration files, see <cite>z/OS Communications Server: IP Configuration Guide</cite>.</li>
<li>For information about modifying the NFS samples, see Chapter 10
in <cite>z/OS Network File System Guide and Reference</cite>.</li></ul>
<h4 id="viparange">IP Services: Review VIPARANGE definitions</h4>
<p>[[[[ Contributing writer: Jeffrey Gates/Durham/Contr/IBM@IBMUS
]]]] [[[[ Technical contacts: Andrew Arrowood/Raleigh/IBM@IBMUS, Sue
Huang/Raleigh/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Prior to z/OS V1R13, for any dynamic VIPA (DVIPA)
creation request, the first matching VIPARANGE statement is used when
creating a DVIPA. Beginning in z/OS V1R13, the most specific VIPARANGE
statement match is used when creating a DVIPA.<a id="idx868"></a></p>
<table id="wq464" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to ensure DVIPAs are created
as intended.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Be aware of the change in VIPARANGE processing.</li>
<li>Update VIPARANGE definitions as needed.</li></ol>
<p><strong>Reference information</strong>: For details, see the following:</p>
<ul>
<li> "VIPARANGE statement" in <cite>z/OS Communications Server: IP Configuration Reference</cite> in</li></ul>
<h4 id="vitrelocate">SNA Services: Adjust to the relocation of the VTAM internal
trace table</h4>
<p>[[[[ Contributing writer: Sonja Moore/Durham/Contr/IBM@IBMUS
]]]] [[[[ Technical contacts: Dave Herr/Raleigh/IBM@IBMUS, Ed Zebrowski/Raleigh/IBM@IBMUS
]]]</p>
<p><strong>Description</strong>: Starting with z/OS V1R13, the VTAM
internal trace (VIT) table is relocated from ECSA to HVCOMMON and
the VIT data space is eliminated. As a result, be aware of the following
changes starting in z/OS V1R13: 
</p>
<ul>
<li>The SIZE parameter of the TRACE start option and the
MODIFY TRACE command is used to set the size of the VTAM Internal
Trace (VIT) table. Prior to z/OS V1R13, the value of the SIZE parameter
specified the number of pages of ECSA (for example, SIZE=999). Starting
with z/OS V1R13, the value of the SIZE parameter of the TRACE start
option and the MODIFY TRACE command specifies the number of megabytes
of HVCOMMON (for example, SIZE=4M).</li>
<li>Starting with z/OS V1R13, the DSPSIZE parameter is not valid.
 

<ul>
<li>The DSPSIZE parameter was used to set the size of the VIT data
space. Prior to z/OS V1R13, the value of the DSPSIZE parameter specified
the number of megabytes of data space in 10 megabytes increments (for
example, DSPSIZE=5 for 50 megabytes).</li>
<li>If DSPSIZE is coded in the VTAM start list, the following
informational message is displayed: IST448I DSPSIZE OPTION IGNORED
- NO LONGER SUPPORTED. Processing then continues disregarding the
specification.</li>
<li>If DSPSIZE is specified on a MODIFY TRACE command, the
following informational message is displayed: <span>IST448I
DSPSIZE OPTION IGNORED - NO LONGER SUPPORTED.</span> The entire MODIFY
TRACE command is ignored. 
<div>
<div class="note-noindent" id="wq466">
<span class="notetitle">Note:</span> <span class="notebody"> Note: In z/OS V1R13, after
applying the PTF for VTAM APAR OA39214, the IST448I message was replaced
with the following message.
<pre class="xmp"><code>IST2365I MODIFY TRACE COMMAND REJECTED - DSPSIZE NO LONGER SUPPORTED </code></pre></span></div></div></li></ul></li>
<li>Numerous messages are no longer issued and are retired.</li></ul>
<table id="wq467" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx869"></a><a id="idx870"></a><a id="idx871"></a><strong>Element
or feature</strong>:</td>
<td>Communications Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if one or more of the following conditions
are true: 

<ul>
<li> If automation of the MODIFY TRACE command exists and the command
specifies SIZE in pages or DSPSIZE, and the failure of that command
is unacceptable.</li>
<li>If automated applications that parse retired messages not finding
any of the newly retired messages is unacceptable.</li></ul></td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td> 

<ul>
<li>Valid SIZE values are 4M-2048M inclusive.</li>
<li>If you specify a SIZE value that is larger than the default value,
z/OS will perform paging on portions of the VIT table. Before you
specify a large SIZE value, ensure that you have sufficient real or
auxiliary storage to contain the entire VIT. Failure to ensure sufficient
storage might result in an auxiliary storage shortage. If an SVC dump
is taken that includes common storage, the size of the dump data set
also increases. You must also take the increase in the size of the
dump data set into consideration.</li></ul></td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>Moving the VIT to HVCOMMON can make up to 999
pages of ECSA available to other applications or subsystems.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None. The VIT associated health checks have
been removed. See <a href="e0z3m100.htm#uplochk">Update your check customization for modified IBM Health Checker for z/OS checks</a> for more
information.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ul>
<li>Migrate your VTAM start lists: 

<p>Although the VTAM internal trace
(VIT) table size is now specified in megabytes and the DSPSIZE parameter
is no longer valid, you are not forced to update your VTAM start lists
before using z/OS V1R13. If you use a nonzero DSPSIZE value in your
start list, your tracing capacity will be diminished unless you perform
these migration tasks. You should convert your SIZE value to megabytes
and delete your DSPSIZE specification.</p></li>
<li>Migrate your automated MODIFY TRACE commands: 

<p>Unlike the VTAM
start lists, the migration of any automation of the MODIFY TRACE command
that specifies the value of the SIZE parameter in pages or the DSPSIZE
parameter is required before using z/OS V1R13 if the failure of that
command is unacceptable. If you fail to perform this migration effort,
the automated command will be rejected, the size of the table will
remain unchanged, and any other modifications specified on the command
(for example, opt=all) will be ignored.</p></li>
<li>Migrate your TRACE option or MODIFY TRACE command when they specify
the SIZE parameter, the DSPSIZE parameter, or both parameters: 

<ol type="1">
<li>If DSPSIZE=0 is specified, delete the specification. If the SIZE
parameter is also specified or you want a table size larger than 4
megabytes, proceed to steps 2, 3, and 4.</li>
<li>If DSPSIZE is not specified, specify the SIZE value as the number
of megabytes you want in your trace table (4 megabytes minimum, for
example, SIZE=4M). <span>Regardless of the size of the VIT,
only a few megabytes are backed by 64-bit real storage. This range
of fixed pages is dynamically shifted as VIT records are written.</span> The
migration task is complete for this start list or automated command.</li>
<li>If the DSPSIZE parameter is specified and the SIZE parameter is
not, change DSPSIZE to SIZE and change the value to the number of
megabytes you want in your trace table (4 megabytes minimum). If you
want to retain the equivalent of what was specified for DSPSIZE, specify
the SIZE value as the DSPSIZE value and append '0M'. For example,
DSPSIZE=1 is equivalent to SIZE=10M. The migration task is complete
for this start list or automated command.</li>
<li>If the DSPSIZE and SIZE parameters are both specified, delete
the DSPSIZE specification and change the value of the SIZE parameter
to the number of megabytes you want in your trace table (4 megabytes
minimum). If you want to retain the equivalent of what was specified
for the DSPSIZE parameter, change the value of the SIZE parameter
to the DSPSIZE value and append '0M'. For example, <span>DSPSIZE=3
is equivalent to SIZE=30M.</span></li></ol></li>
<li>Migrate applications that parse retired messages: 

<p>If you have
automation that parses the output from the MODIFY TRACE, DISPLAY TRACE,
or DISPLAY STATS command, you might need to update them because the
VIT size is now reported in megabytes. Also, you will no longer see
DSPSIZE reported as the VIT data space has been removed.</p> 

<p>In
addition, numerous messages are retired because they no longer apply.
As a result, perform the following steps: 
</p>
<ul>
<li>If you run automation that parses the output of the MODIFY or
DISPLAY TRACE command, change the automation to process megabytes
instead of pages. 

<p>Previous message: <samp class="xph">IST315I  VTAM INTERNAL
TRACE ACTIVE - MODE = INT, SIZE = <em>size</em> PAGES</samp></p> 

<p>Updated
message: <samp class="xph">IST315I  VTAM INTERNAL TRACE ACTIVE - MODE = INT,
SIZE = <em>size</em> MB</samp></p></li>
<li>If you run automation that parses the output of the DISPLAY STATS
command, change the automation to process megabytes instead of pages. 

<p>Previous
message: <samp class="xph">IST1227I     2        999 = VIT TABLE SIZE</samp></p> 

<p>Updated
message: <samp class="xph">IST1227I     2        4 = VIT TABLE SIZE</samp></p> 

<p>Also,
you will no longer see the following message because the VIT data
space has been removed:</p> 

<p><samp class="xph">IST1227I   163          0 =
VIT DATA SPACE TABLE SIZE</samp></p></li>
<li>If you run automation that parses any of the following
messages, delete the automation because the messages are either retired
or no longer used for the VIT. 

<p><samp class="xph">IST318I VTAM INTERNAL TRACE
ACTIVATION FAILED -- UNABLE TO FIX STORAGE</samp></p> 

<p><samp class="xph">IST495I <em>type</em> HAS
BEEN SET TO <em>value</em></samp></p> 

<p><samp class="xph">IST1659I
DATA SPACE <em>dspname</em> DSPSIZE = <em>dspsize actsize</em></samp></p> 

<p><samp class="xph">IST1741I
DATA SPACE SDUMPX FAILED WITH RETURN CODE <em>code</em> REASON <em>reason</em></samp></p> 

<p><samp class="xph">ISTH003I
The VTAM Internal Trace (VIT) table size is at the maximum value,
which provides optimal trace information for problem determination</samp></p> 

<p><samp class="xph">ISTH004E
VTAM Internal Trace (VIT) table size of vit_size is too small</samp></p> 

<p><samp class="xph">ISTH007I
VTAM Internal Trace (VIT) dataspace size is at the maximum value,
which provides optimal trace information for problem determination</samp></p> 

<p><samp class="xph">ISTH008E
VTAM Internal Trace (VIT) dataspace size of dspsize is too small</samp></p> 

<p><samp class="xph">IVT5602I
DATA SPACE SDUMPX FAILED WITH RETURN CODE <em>code</em> REASON <em>reason</em></samp></p></li></ul></li>
<li>Other automation: 

<p>If you have automation that parses for or
specifies the character string ISTITDS1, which <span>prior
to z/OS V1R13</span> was the name of the data space containing the VIT
data space, you might want to modify that automation because the data
space will no longer be created. This is highly recommended if you
have SLIP traps that dump the VIT data space.</p>
<div>
<div class="note-noindent" id="wq469">
<span class="notetitle">Note:</span> <span class="notebody">
<ul>
<li>Failure to remove the DSPNAME for non-existent data spaces can
result in an error message but should not preclude the running process</li>
<li>Check for dump commands that use DSPNAME=('VTAM'.ISTITDS1) and
remove the DSPNAME parameter. Note that VTAM uses additional data
spaces, so you should not remove any DSPNAME parameter that specifies
a wildcard data space name.</li>
<li> Because FFST dumps do not include data spaces, they are not affected.</li></ul></span></div></div></li></ul>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li>See  in <cite>z/OS Communications Server: SNA Resource Definition Reference</cite> for
additional information about specifying the size of the VTAM internal
trace (VIT) table using the VTAM TRACE start option.</li>
<li>See  in <cite>z/OS Communications Server: SNA Operation</cite> for
additional information about specifying the size of the VTAM internal
trace (VIT) table using the MODIFY TRACE command.</li></ul>
<h3 id="e0z3m100-gen104">Communications Server actions to perform after the first IPL
of z/OS V2R1</h3>
<p>This topic describes Communications Server migration actions that
you can perform only after you have IPLed z/OS V2R1. You need a running z/OS V2R1 system to perform these actions.</p>
<p>None.<a id="idx872"></a><a id="idx873"></a><a id="idx874"></a><a id="idx875"></a><a id="idx876"></a><a id="idx877"></a></p>
<h2 id="ae1cryp1">Cryptographic Services migration actions</h2>
<p>This topic describes migration actions for base element Cryptographic
Services. Included are the components Integrated Cryptographic Service
Facility (ICSF), Open Cryptographic Services Facility (OCSF), PKI
Services, and System Secure Sockets Layer (SSL).</p>
<h3 id="e0z3m100-gen105">Cryptographic Services actions to perform before installing
z/OS V2R1</h3><a id="idx878"></a><a id="idx879"></a><a id="idx880"></a>
<p>This topic describes Cryptographic Services migration actions that
you can perform on your current (old) system. You do not need the z/OS V2R1 level of code to make
these changes, and the changes do not require the z/OS V2R1 level of code to run once they are
made.</p>
<p>None.<a id="idx881"></a><a id="idx882"></a><a id="idx883"></a><a id="idx884"></a></p>
<p>Reviewers: There are new crypto actions that will appear
in the next eReview</p>
<h3 id="dt2mg648">Cryptographic Services actions to perform before the first
IPL of z/OS V2R1</h3>
<p>This topic describes Cryptographic Services migration actions that
you can perform after you have installed z/OS V2R1 but before the first time you IPL.
These actions might require the z/OS V2R1
level of code to be installed but do not require it to be active.</p>
<p><a href="e0z3m100.htm#pkcs111">ICSF: Start using ICSF in FIPS mode for PKCS #11 Diffie Hellman
support to generate key parameters, key pairs, and key exchanges</a></p>
<p><a href="e0z3m100.htm#icsfcsfpu">ICSF: Ensure the CSFPUTIL utility is not used to initialize
a PKDS</a></p>
<p><a href="e0z3m100.htm#ae3ois">OCSF: Migrate the directory structure</a></p>
<p><a href="./SSL_V2R1_sslfips_v2r1_12.html">System SSL: Ensure ICSF is available when running System SSL
in FIPS mode</a></p>
<p><a href="e0z3m100.htm#csfserv">System SSL:  Ensure all RACF user IDs that start SSL applications
in non-FIPS mode can access the CSFRNG resource of the CSFSERV class</a></p>
<p><a href="e0z3m100.htm#dt2mg655">System SSL: Ensure all RACF user IDs that start SSL applications
can access the CSFIQA resource of the CSFSERV class</a></p>
<h4 id="dt2mg651">ICSF: Start using ICSF in FIPS mode for PKCS #11 Diffie Hellman
support to generate key parameters, key pairs, and key exchanges</h4>
<p>[[[[ Marna Walle]]]]</p>
<p>In z/OS V2R1, System Security uses the ICSF PKCS #11 CSFPPRF pseudo-random
function for generation of random data. In non-FIPS mode the previous
software implementation remains as a back up random number generator;
however, in FIPS mode, this backup will be unavailable..</p>
<table id="wq470" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Cryptographic Services.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>ICSF FMID HCR77A1, which was initially made
available in web deliverable Cryptographic Support for z/OS V1R13-V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ul>
<li>Review applications that uses Security Server SSL in both non-FIPS
or FIPS mode.</li>
<li>For FIPS-mode applications: 

<ul>
<li>Ensure ICSF has been configured and started on the system
in FIPS mode.</li>
<li>Ensure that the application userID has READ access to at least
the CSFRNG resource in the RACF CSFSERV class, if the CSFSERV class
has been defined.</li>
<li>If the application uses Diffie-Hellman by specifying either a
Diffie-Hellman cipher for a SSL/TLS handshake, using Diffie-Hellman
certificates, or creating Diffie-Hellman key parameters and keys,
ensure the application userID has READ access to the CSF1TRC, CSF1DVK,
CSF1GKP, CSF1GSK, CSF1GAV and CSF1TRD resources in the RACF CSFSERV
class, if the CSFSERV class has been defined.</li></ul></li>
<li>For non-FIPS mode applications: 

<ul>
<li>If ICSF has been configured and started on the system, ensure
the application userID has READ access to at least the CSFRNG resource
in the RACF CSFSERV class, if the CSFSERV class has been defined.
 Without access to the resource, informational message ICH408I will
be displayed and System SSL will switch to using its software version
of Random Number Generate.</li></ul></li></ul>
<p><strong>Reference information</strong>: <cite>z/OS Cryptographic Services System SSL Programming</cite>.</p>
<h4 id="icsfcsfpu">ICSF: Ensure the CSFPUTIL utility is not used to initialize
a PKDS</h4><a id="idx885"></a><a id="idx886"></a><a id="idx887"></a><a id="idx888"></a><a id="idx889"></a><a id="idx890"></a>
<p>[[[[ Contributing writer: Timothy B Flaherty/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: James Sweeny/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: ICSF provides a utility program, CSFPUTIL,
that performs certain functions that can also be performed using the
administrator&rsquo;s panels. In releases of ICSF prior to FMID HCR7780
(available as web deliverable <em>Cryptographic Support for z/OS V1R10-V1R12</em>), you could
use the CSFPUTIL utility program to initialize a PKDS, reencipher
a PKDS, and refresh the in-storage copy of the PKDS. You can still
use the CSFPUTIL utility to reencipher or refresh a PKDS. However,
starting with FMID HCR7780 (<em>Cryptographic Support for z/OS V1R10-V1R12</em>, now integrated into z/OS
V1R13), the CSFPUTIL utility program no longer supports the function
to initialize a PKDS. Instead, the ICSF panels must be used to initialize
a PKDS.</p>
<p><a id="idx891"></a><a id="idx892"></a></p>
<table id="wq471" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Cryptographic Services.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>ICSF FMID HCR7780, which was initially made
available in web deliverable Cryptographic Support for z/OS V1R10-R12
and is integrated into z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12 without ICSF FMID HCR7780 installed.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have jobs that use the CSFPUTIL
utility program to initialize a PKDS.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>Because of this change, jobs that call the CSFPUTIL
utility with the INITPKDS option will no longer initialize a PKDS,
and return code 4 (which indicates that supplied parameters are incorrect)
will be returned.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Make sure no jobs call CSFPUTIL with the
INITPKDS option. Use the administrator panels to initialize the PKDS
instead.</p>
<p><strong>Reference information</strong>: For more information in initializing
the PKDS and on the CSFPUTIL utility, refer to <cite>z/OS Cryptographic Services ICSF Administrator&amp;apos;s Guide</cite>.</p>
<h4 id="dt2mg652">OCSF: Migrate the directory structure</h4><a id="idx893"></a><a id="idx894"></a><a id="idx895"></a><a id="idx896"></a><a id="idx897"></a><a id="idx898"></a>
<p><strong>Description</strong>: If you previously configured Open Cryptographic
Services Facility (OCSF), you need to verify that the OCSF directories
have been migrated to the target system.
 </p>
<div>
<div class="note-noindent" id="wq472">
<span class="notetitle">Note:</span> <span class="notebody"> If you want to take advantage of the new Software
Cryptographic Service Provider 2 (SWCSP2), you should bypass this
migration action.  When your system is up and running, install OCSF
by running the install script and then the IVP.</span></div></div><a id="idx899"></a>
<table id="wq473" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Cryptographic Services.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you currently use OCSF or if new products
or functions on your new z/OS system require OCSF to be active. However,
if you installed your new z/OS system
with ServerPac or SystemPac,
the OCSF installation script has been run and you do not have to perform
this migration action for that system.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Migrate the OCSF <samp class="xph">/var</samp> directory
structure to the target system. If you installed z/OS V1R11 with CBPDO or by cloning an already-installed
V1R11 system, you can either copy  the <samp class="xph">/var/ocsf</samp> directory
from your old system or rerun the installation script. If you installed z/OS V1R11 with ServerPac or SystemPac, the OCSF installation
script has been run and you have no migration actions for that target
system (although you still have to migrate the directory structure
to any cloned systems, as stated above).</p>
<p>If you copy <samp class="xph">/var/ocsf</samp>, verify that the OCSF <samp class="xph">/var</samp> directory
structure has been migrated to the target system as described in <a href="e0z3m100.htm#at3gend">Migrate /etc and /var system control files</a>. The OCSF registry (the <samp class="xph">/var/ocsf</samp> files)
contains the directory path names to the code libraries. If the registry
files are copied, the CSSM DLL and the add-ins must be in the same
location on the target system as on the prior release.  The normal
locations are <samp class="xph">/usr/lpp/ocsf/lib</samp> for the CSSM and
supporting DLLs and <samp class="xph">/usr/lpp/ocsf/addins</samp> for the
add-in libraries.</p>
<p>If you copied <samp class="xph">/var/ocsf</samp>, do the following:</p>
<ol type="1">
<li>Verify that the following four files exist in that directory: 

<ul>
<li>CDSA_Registry.dir with permissions (-rw-r--r--)</li>
<li>CDSA_Registry.pag with permissions ( -rw-r--r--)</li>
<li>CDSA_Sections.dir with permissions (-rw-r--r-- )</li>
<li>CDSA_Sections.pag with permissions (-rw-r--r--)</li></ul></li>
<li>Verify that the required RACF FACILITY
class profiles are defined and set up:<a id="idx900"></a>  

<ul>
<li>CDS.CSSM -- authorizes the daemon to call OCSF services</li>
<li>CDS.CSSM.CRYPTO -- authorizes the daemon to call a cryptographic
service provider (CSP)</li>
<li>CDS.CSSM.DATALIB -- authorizes the daemon to call a data storage
library (DL) service provider</li></ul></li>
<li>Ensure that the necessary libraries are program controlled: 

<ul>
<li>XL C/C++ runtime libraries</li>
<li>Language Environment libraries</li>
<li>SYS1.LINKLIB</li>
<li>SYS1.SIEALNKE</li></ul></li></ol>
<p>If you did not copy <samp class="xph">/var/ocsf</samp>, rerun the installation
script:</p>
<ol type="1">
<li>Set up the RACF FACILITY
class profiles required by OCSF and authorize the appropriate
user IDs to those profiles: 

<ul>
<li>CDS.CSSM -- authorizes the daemon to call OCSF services</li>
<li>CDS.CSSM.CRYPTO -- authorizes the daemon to call a cryptographic
service provider (CSP)</li>
<li>CDS.CSSM.DATALIB -- authorizes the daemon to call a data storage
library (DL) service provider</li></ul></li>
<li>Ensure that the following libraries are defined as program controlled: 

<ul>
<li>XL C/C++ runtime libraries</li>
<li>Language Environment libraries</li>
<li>SYS1.LINKLIB</li>
<li>SYS1.SIEALNKE</li></ul></li>
<li>Run the <strong>ocsf_install_crypto</strong> script from the OMVS shell.
This must be run from the target system.  

<ol type="a">
<li>Verify and update $LIBPATH.</li>
<li>Change directory to the location of the script (<samp class="xph">/usr/lpp/ocsf/bin</samp>).</li>
<li>Run the script.</li></ol></li></ol>
<p>Whether you reinstalled or migrated, it is strongly recommended
that you rerun IVP <strong>ocsf_baseivp</strong> from the OMVS shell. This IVP
verifies that OCSF is installed and configured correctly. To run the
IVP:</p>
<ol type="1">
<li>Mount <samp class="xph">/usr/lpp/ocsf/ivp</samp>.</li>
<li>Read the README file and follow the instructions.</li>
<li>Run the IVP.</li></ol>
<p>If you were using other IBM or
non-IBM services to supplement the functions in OCSF, such as the
Open Cryptographic Enhanced Plug-ins (OCEP) component of base element
Integrated Security Services, or the PKI Services component of base
element Cryptographic Services, you must ensure that these are migrated
or reinstalled.</p>
<p><strong>Reference information</strong>: .</p>
<h4 id="dt2mg653">System SSL: Ensure ICSF is available when running System SSL
in FIPS mode</h4><a id="idx901"></a><a id="idx902"></a>
<p>[[[[ Tim Flaherty ]]]] [[[[ Technical
contact: Alyson Comer ]]]]</p>
<p><strong>Description</strong>: In z/OS V2R1, System SSL, when running
in FIPS mode, uses ICSF's random number generation and Diffie-Hellman
support. Before running System SSL in FIPS mode you must ensure that
ICSF is running and that all user IDs that start SSL applications
in FIPS mode, invoke the gskkyman utility to manage FIPS
key database files, or invoke the GSKSRVR started task in FIPS mode
have access to certain CSFSERV classes.</p>
<p>When it is running in non-FIPS mode, System SSL uses its
own implementation of Diffie-Hellman and does not require ICSF. In
non-FIPS mode, however, System SSL attempts to use ICSF's random number
generation as it would when running in FIPS mode. If ICSF or the required
resource is unavailable, System SSL uses its own random number generation
capabilities as in earlier releases.</p>
<table id="wq478" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx903"></a><a id="idx904"></a><strong>Element
or feature</strong>:</td>
<td>Cryptographic Services.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td align="left">ICSF FMID HCR77A1, which was initially
made available in web deliverable Cryptographic Support for z/OS V1R13-V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your installation runs System SSL in
FIPS mode.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: To run System SSL in FIPS mode,
you must now make sure that ICSF is running and that all user IDs
that start SSL applications in FIPS mode, invoke the GSKSRVR started
task in FIPS mode, or invoke the gskkyman utility to manage
FIPS key database files can access the necessary ICSF callable services.</p>
<p></p>
<ol type="1">
<li>Make sure that ICSF is running. Assuming CSF is the name of the
ICSF started task, you would enter:
<pre class="xmp"><code>DISPLAY A,CSF*</code></pre>

<p>To
display status about all started tasks, you would enter:</p>
<pre class="xmp"><code>DISPLAY A,ALL</code></pre>

<p>In
z/OS V1R12 and V1R13, System SSL is providing capability to identify
System SSL applications that are running in FIPS mode, which are started
before ICSF is available.  Identification of these applications is
done by using the System SSL started task (GSKSRVR) and the z/OS tracking
facility.  This migration assistance support is delivered in APAR
OA40816. See <em>Documentation updates for FIPS ICSF tracking support</em> for
more information.</p></li>
<li>System SSL applications that are running in FIPS mode, the GSKSRVR
started task that is running in FIPS mode, and the gskkyman utility
(if managing FIPS key database files) must be able to access ICSF's
PKCS #11 pseudo-random function callable service for random number
generation. In addition, applications and the gskkyman utility
must access the following callable services to use ICSF's Diffie-Hellman
capabilities:

<ul>
<li>PKCS #11 Token record create</li>
<li>PKCS #11 Derive key</li>
<li>PKCS #11 Generate key pair</li>
<li>PKCS #11 Generate secret key</li>
<li>PKCS #11 Get attribute value</li>
<li>PKCS #11 Token record delete</li></ul>To ensure that RACF user IDs have access to the necessary services:

<ol type="a">
<li>Determine if the CSFSERV class is active. If active, this class
restricts access to the ICSF programming interface. If it is not active,
access to the ICSF programming interface (and the necessary callable
services) is unrestricted. No configuration is necessary.

<p>To determine
which RACF classes are currently active, enter the SETROPTS command
with the LIST parameter specified.SETROPTS LIST</p></li>
<li>If the SETROPTS LIST command shows that the CSFSERV class is active,
identify the profile or profiles that cover the following resources:

<ul>
<li>CSFRNG (which represents the PKCS #11 Pseudo-random function callable
service)</li>
<li>CSF1TRC (which represents the PKCS #11 Token record create callable
service)</li>
<li>CSF1DVK (which represents the PKCS #11 Derive key callable service)</li>
<li>CSF1GKP (which represents the PKCS #11 Generate key pair callable
service)</li>
<li>CSF1GSK (which represents the PKCS #11 Generate secret key callable
service)</li>
<li>CSF1GAV (which represents the PKCS #11 Get attribute value callable
service)</li>
<li>CSF1TRD (which represents the PKCS #11 Token record delete callable
service)</li></ul>Each of these resources can be covered by a discrete profile
or, if generic profile checking is activated, a generic profile. You
can use the RLIST command to determine if a profile is defined to
protect each resource. For example, to determine if a profile is defined
to protect the CSFRNG resource, enter the following RLIST command:
RLIST CSFSERV CSFRNG. When you enter this command, RACF lists information
for the discrete profile CSFRNG. If there is no matching discrete
profile, RACF lists the generic profile that most closely matches
the resource name.</li>
<li>If the RLIST command output reveals that there is a discrete or
generic profile that covers the resource, examine the command output
to ensure that all RACF user IDs that might start System SSL applications
in FIPS mode have at least READ access to the resource. If necessary,
use the PERMIT command to give the appropriate users or groups access.
For example, if a discrete profile CSFRNG exists, the following command
would give the user JASMINE access:
<pre class="xmp"><code>PERMIT CSFRNG CLASS(CSFSERV) ID(JASMINE) ACCESS(READ)</code></pre>If
you do make changes, refresh the in-storage RACF profiles for the
CSFSERV class: SETROPTS RACLIST(CSFSERV) REFRESH</li></ol></li></ol>
<p><strong>Documentation updates for FIPS ICSF tracking support:</strong></p>
<p>This documentation contains updates to the following chapters of
z/OS V1R12 and V1R13 <cite>z/OS Cryptographic Services System SSL ProgrammingSC14-7495</cite>:
</p>
<ul>
<li>System SSL and FIPS 140-2: Added a section about how to enable
and use the migration assistance support.</li>
<li>SSL started task chapter: Added GSKSRVR environment variable definitions.</li>
<li>Messages and codes, SSL started task messages (GSK01nnn) section:
Added SSL started task messages, GSK01058I, GSK01059I, GSK01060E,
GSK01061I GSK01062I, and GSK01063I</li></ul>
<p><strong>Reference information</strong>: For additional information about
System SSL use of ICSF callable services, see<cite>z/OS Cryptographic Services System SSL Programming, SC14-7495</cite>.</p>
<p>For additional information on the ICSF installation options file,
refer to <cite>z/OS Cryptographic Services ICSF System Programmer&amp;apos;s Guide</cite>.</p>
<p>For additional information about ICSF's CSFSERV resource class
and the Installation Option Display panel, refer to <cite>z/OS Cryptographic Services ICSF Administrator&amp;apos;s Guide, SA22-7521</cite>.</p>
<h4 id="dt2mg654">System SSL:  Ensure all RACF user IDs that start SSL applications
in non-FIPS mode can access the CSFRNG resource of the CSFSERV class</h4>
<p>[[[[ Tim Flaherty ]]]] [[[[ Technical
contact: Alyson Comer ]]]]</p>
<p><strong>Description</strong>: Before z/OS V2.1, System SSL always
used its own random number generation support available in software.
As of z/OS V2R1, System SSL now exploits ICSF random number generation
support if ICSF is available. In order to utilize ICSF when the random
number generation service is protected by a RACF resource profile
(CSFRNG), the userid under which the application is executing must
have at least READ access to the resource profile. If the application
is not FIPS enabled the processing is able to fall back to our software
implementation and allow the application to continue (as a result,
you might receive RACF unauthorized messages). If the application
is FIPS enabled, it will fail.</p>
<p>If the user ID that starts the SSL application cannot
access the CSFRNG resource of the CSFSERV class, System SSL will not
be able to use the PKCS #11 Pseudo-random function callable service,
and the informational message ICH408I (which indicates insufficient
authorization) may be issued to the console. Although System SSL processing
will continue, your application will be using System SSL's random
number generation and will not be exploiting the random number generation
capability provided by ICSF software or the Crypto Express3 Coprocessor
(Crypto Express3 Coprocessor card or Crypto Express4 Coprocessor card).</p>
<table id="wq481" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx905"></a><a id="idx906"></a><strong>Element
or feature</strong>:</td>
<td>Cryptographic Services.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>ICSF FMID HCR77A1, which was initially made
available in web deliverable Cryptographic Support for z/OS V1R13-V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the following conditions are true:

<ul>
<li>Your installation uses ICSF.</li>
<li>The CSFSERV general resource class is active.</li>
<li>A profile covering the CSFRNG resource of the CSFSERV class is
defined and does not grant READ access to all users.</li></ul></td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>CSF might employ one of multiple techniques
to derive the random content. For both FIPS certified random content
and for non-FIPS certified random content, the availability of CCA
and/or PKCS #11 coprocessors enables ICSF to derive the random content
without imposing significant CPU overhead on the system. Either type
of coprocessor can be exploited for non-FIPS certified content, but
only a PKCS #11 coprocessor can be used to avoid CPU cycles for FIPS
certified random content. Installations may wish to plan for CCA and/or
PKCS #11 coprocessor availability to avoid potentially excessive CPU
cycles being exhausted on random number content generation.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>The system issues informational message ICH408I
that indicates insufficient authorization might be issued to the console.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If your installation uses ICSF, you should
ensure that any RACF user ID that will start SSL applications can
access the CSFRNG callable service. This includes the SSL started
task (GSKSRVR), and the <strong>gskkyman</strong> and <strong>gsktrace</strong> utilities.</p>
<ol type="1">
<li>Determine if the CSFSERV class is active. If active, this class
restricts access to the ICSF programming interface. If it is not active,
access to the ICSF programming interface (and specifically the CSFRNG
callable service) is unrestricted. No configuration is necessary.
  

<p>To determine which RACF classes are currently active, enter the
SETROPTS command with the LIST parameter specified: </p>
<pre class="xmp"><code>SETROPTS LIST</code></pre></li>
<li>If the SETROPTS LIST command shows that the CSFSERV class is active,
identify the profile that covers the CSFRNG resource. This could be
a discrete profile named CSFRNG or, if generic profile checking is
activated, a generic profile.   

<p>To determine if a profile has been
defined to protect the CSFRNG resource, enter the following RLIST
command: </p>
<pre class="xmp"><code>RLIST CSFSERV CSFRNG</code></pre>When you enter
this command, RACF lists information for the discrete resource profile
CSFRNG.  If there is no matching discrete profile, RACF will list
the generic profile that most closely matches the resource name.</li>
<li>If the RLIST command output revealed that there is a discrete
or generic profile defined that covers the CSFRNG resource, examine
the command output to ensure that all RACF user IDs that may start
System SSL applications have at least READ access to the CSFRNG resource.
If necessary, use the PERMIT command to give the appropriate users
or groups access. For example, if a discrete profile CSFRNG exists,
the following command would give user BAILEY access.   
<pre class="xmp"><code>PERMIT CSFRNG CLASS(CSFSERV) ID(BAILEY) ACCESS(READ)</code></pre> If
you do make any changes, refresh the in-storage RACF profiles for
the CSFSERV class:   
<pre class="xmp"><code>SETROPTS RACLIST(CSFSERV) REFRESH</code></pre></li></ol>
<p><strong>Reference information</strong>: For additional information about
System SSL's use of ICSF callable services, refer to <cite>z/OS Cryptographic Services System SSL Programming, SC14-7495</cite>.</p>
<p>For additional information on the ICSF installation options file,
refer to <cite>z/OS Cryptographic Services ICSF System Programmer&amp;apos;s Guide</cite>.</p>
<p>For additional information about ICSF's CSFSERV resource class
and the Installation Option Display panel, refer to <cite>z/OS Cryptographic Services ICSF Administrator&amp;apos;s Guide, SA22-7521</cite>.</p>
<h4 id="dt2mg655">System SSL: Ensure all RACF user IDs that start SSL applications
can access the CSFIQA resource of the CSFSERV class</h4><a id="idx907"></a><a id="idx908"></a>
<p>[[[[ Contributing writer: Sonja Moore/Durham/Contr/IBM@IBMUS
]]]] [[[[ Original technical contact: Greg Callis/Raleigh/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: When the System SSL DLLs are loaded, System
SSL determines which hardware is available. Starting in z/OS V1R13,
System SSL uses the ICSF Query Algorithm callable service (CSFIQA)
to retrieve information about the cryptographic algorithms that are
available. However, if the user ID that starts the SSL application
cannot access the CSFIQA resource of the CSFSERV class, System SSL
will not be be able to retrieve information using the CSFIQA callable
service, and the informational message ICH408I (which indicates insufficient
authorization) may be issued to the console. Although System SSL processing
will continue, System SSL may not be aware of all the hardware that
is currently available.</p>
<table id="wq483" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td></td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td align="left">ICSF FMID HCR7780, which was initially
made available in web deliverable Cryptographic Support for z/OS V1R10-R12
and is now integrated into z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td align="left">Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the following conditions are true:

<ul>
<li>Your installation uses ICSF,</li>
<li>The CSFSERV general resource class is active.</li>
<li>A profile covering the CSFIQA resource of the CSFSERV class is
defined and does not grant READ access to all users</li></ul></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>ZOSMIGV2R1_CS_GATEWAY can help you determine
if you are using any GATEWAY statements in your TCP/IP profile.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If your installation uses ICSF, you should
ensure that any RACF user ID that will start SSL applications can
access the CSFIQA callable service. This includes the SSL started
task (GSKSRVR), and the gskkyman and gsktrace utilities.
</p>
<ol type="1">
<li>Determine if the CSFSERV class is active. If active, this class
restricts access to the ICSF programming interface. If it is not active,
access to the ICSF programming interface (and specifically the CSFIQA
callable service) is unrestricted. No configuration is necessary.
To determine which RACF classes are currently active, enter the SETROPTS
command with LIST parameter specified: 
<pre class="xmp"><code>SETROPTS LIST</code></pre></li>
<li>If the SETROPTS LIST command shows that the CSFSERV class is active,
identify the profile that covers the CSFIQA resource. This could be
a discrete profile named CSFIQA or, if generic profile checking is
activated, a generic profile. To determine if a profile has been defined
to protect the CSFIQA resource, enter the following RLIST command: 
<pre class="xmp"><code>RLIST CSFSERV</code></pre> CSFIQA
When you enter this command, RACF lists information for the discrete
resource profile CSFIQA. If there is no matching discrete profile,
RACF will list the generic profile that most closely matches the resource
name.</li>
<li> If the RLIST command output revealed that there is a discrete
or generic profile defined that covers the CSFIQA resource, examine
the command output to ensure that all RACF user IDs that may start
System SSL applications have at least READ access to the CSFIQA resource.
If necessary, use the PERMIT command to give the appropriate users
or groups access. For example, if a discrete profile CSFIQA exists,
the following command would give user BAILEY access. 
<pre class="xmp"><code>PERMIT CSFIQA CLASS(CSFSERV) ID(BAILEY) ACCESS(READ)</code></pre> If
you do make any changes, refresh the in-storage RACF profiles for
the CSFSERV class: 
<pre class="xmp"><code>SETROPTS RACLIST(CSFSERV) REFRESH</code></pre></li></ol>
<p><strong>Reference information:</strong> For additional information about
System SSL use of ICSF callable services, see <cite>z/OS Cryptographic Services System SSL Programming</cite></p>
<p>For additional information about ICSF CSFSERV resource class, see</p>
<h3 id="e0z3m100-gen107">Cryptographic Services actions to perform after the first IPL
of z/OS V2R1</h3>
<p>This topic describes Cryptographic Services migration actions that
you can perform only after you have IPLed z/OS V2R1. You need a running z/OS V2R1 system to perform these actions.</p>
<h4 id="dt2mg657">ICSF: Ensure the expected master key support is available</h4><a id="idx909"></a><a id="idx910"></a><a id="idx911"></a><a id="idx912"></a>
<p>[[[[ Contributing writer: Sonja Moore/Durham/Contr/IBM@IBMUS
]]]] [[[[ Original technical contact: Greg Callis/Raleigh/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>:  In versions of ICSF before FMID HCR7780, in
order for a coprocessor to become active, a DES master key needed
to be set on the coprocessor. Once the coprocessor was active, DES
master key support, and the support of any other master key (an AES
master  key or an asymmetric master key) set on the coprocessor, would
then be availab</p>
<p>Starting with ICSF FMID HCR7780, the activation procedure for non-CCF
systems is designed to maximize the number of active coprocessors
by selecting the set of master keys that are available on the majority
of coprocessors. A DES master key is no longer required in order for
a coprocessor to become active. Instead, any one of four master keys
- the DES master key, the AES master key, the RSA master key (which
in earlier releases was called the asymmetric master key), or the
ECC master key - is enough for a  coprocessor to become active. However,
because the goal is to select the combination of master keys that
will maximize the number of  active coprocessors, if a certain master
key is not set on all the same coprocessors, that master key support
will not be available. Before you use ICSF FMID HCR7780, you must
understand the new method of coprocessor activation in order to ensure
that the expected master keys will be available. You may need to set
master keys on additional coprocessors to ensure the same master key
support you had in earlier versions of ICSF is available in ICSF FMID
HCR7780.</p>
<table id="wq485" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Cryptographic Services</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td align="left">ICSF FMID HCR7780, which was initially
made available in web deliverable Cryptographic Support for z/OS V1R10-R12
and is now integrated into z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12 without ICSF FMID HCR7780 installed.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td align="left">After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>ZOSMIGV2R1_CS_GATEWAY can help you determine
if you are using any GATEWAY statements in your TCP/IP profile.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Make sure you understand the new method of
coprocessor activation described in this migration action to ensure
the expected master key support is available.</p>
<table id="wq486" width="100%" summary="" border="1" frame="border" rules="all" class="presentation" role="presentation">
<thead valign="bottom">
<tr valign="bottom">
<th id="wq487" align="left"></th>
<th id="wq488" align="center">E00</th>
<th id="wq489" align="center">E01</th>
<th id="wq490" align="center">E02</th>
<th id="wq491" align="center">E03</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq487">DES</td>
<td align="center" headers="wq488">Y</td>
<td align="center" headers="wq489"></td>
<td align="center" headers="wq490">Y</td>
<td align="center" headers="wq491"></td>
</tr>
<tr>
<td headers="wq487">AES</td>
<td align="center" headers="wq488">Y</td>
<td align="center" headers="wq489">Y</td>
<td align="center" headers="wq490">Y</td>
<td align="center" headers="wq491">Y</td>
</tr>
<tr>
<td headers="wq487">RSA (ASYM)</td>
<td align="center" headers="wq488">Y</td>
<td align="center" headers="wq489"></td>
<td align="center" headers="wq490">Y</td>
<td align="center" headers="wq491"></td>
</tr>
</tbody>
</table>
<p>In releases before ICSF FMID HCR7780, a DES master key was required
in order for a coprocessor to become active. In our example, coprocessors
E00 and E02 have the DES master key set, so they become active. The
DES master key is available as well as the AES and RSA (ASYM) master
keys which are set on the E00 and E02 coprocessors. Coprocessors E01
and E03 do not have a DES master key set, and so are not active.</p>
<p>Starting with ICSF FMID HCR7780, any master key is enough for a
coprocessor to become active and the activation procedure tries to
maximize the number of active coprocessors. The AES master key is
set on all four of these coprocessors, so all four of the coprocessors
become active. However, since the DES and RSA master keys are not
set on all four of the coprocessors, DES and RSA support is not  available.
As coprocessor master keys are set or changed, however, additional
function may become available. In this case, setting the DES and RSA
master keys on coprocessors E01 and E03 would make the DES and RSA
support available.</p>
<p>ECC master key support is based on the existence of CEX3C coprocessors.
If a mixture of CEX3C coprocessors and older coprocessors exist on
a system, then ECC support will be based solely on the state of the
CEX3C coprocessors. For example, let's change our example so that
 two of the coprocessors are CEX3C coprocessors (as identified by
the G prefix in the name) with the ECC master key set.</p>
<table id="wq492" width="100%" summary="" border="1" frame="border" rules="all">
<caption class="tbldesc"> Coprocessor activation example (ECC support based only
on CEX3C coprocessors)</caption>
<thead valign="bottom">
<tr valign="bottom">
<th id="wq493" align="left"></th>
<th id="wq494" align="center">G00</th>
<th id="wq495" align="center">E01</th>
<th id="wq496" align="center">G02</th>
<th id="wq497" align="center">E03</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq493">DES</td>
<td align="center" headers="wq494">Y</td>
<td align="center" headers="wq495"></td>
<td align="center" headers="wq496">Y</td>
<td align="center" headers="wq497"></td>
</tr>
<tr>
<td headers="wq493">AES</td>
<td align="center" headers="wq494">Y</td>
<td align="center" headers="wq495">Y</td>
<td align="center" headers="wq496">Y</td>
<td align="center" headers="wq497">Y</td>
</tr>
<tr>
<td headers="wq493">RSA (ASYM)</td>
<td align="center" headers="wq494">Y</td>
<td align="center" headers="wq495"></td>
<td align="center" headers="wq496">Y</td>
<td align="center" headers="wq497"></td>
</tr>
<tr>
<td headers="wq493">ECC</td>
<td align="center" headers="wq494">Y</td>
<td align="center" headers="wq495"></td>
<td align="center" headers="wq496">Y</td>
<td align="center" headers="wq497"></td>
</tr>
</tbody>
</table>
<p>In this example, the AES master key is still the one set on the
majority of coprocessors and makes the coprocessors active. The DES
and RSA master keys are not set on all the coprocessors, and so DES
and RSA support is not available. The ECC master key cannot be set
on all coprocessors (because it is not available on the CEX2C). However,
unlike the DES and RSA support, ECC support is still available. This
is because the ECC master key is set on  all CEX3C coprocessors.</p>
<p>To ensure the master key support that you expect is available,
follow these steps:
</p>
<ol type="1">
<li>To ensure AES support, set the AES master key on each CEX2C and
CEX3C.</li>
<li>To ensure DES support, set the DES master key on each CEX2C, CEX3C,
and (as long as AES support is not also needed) PCIXCC.</li>
<li>To ensure RSA support, set the RSA master key on each CEX2C, CEX3C,
and (as long as AES support is not also needed) PCIXCC.</li>
<li>To ensure ECC support, set the ECC master key on each CEX3C.</li></ol>
<p>To verify the master key support is available, select option 1,
COPROCESSOR MGMT, from the ICSF Primary menu. This will display the
coprocessor management panel, which shows which coprocessors are active,
and the state of the master keys for coprocessors.</p>
<p><strong>Reference information:</strong> 
</p>
<ul>
<li>For information about entering master key parts, see <cite>z/OS Cryptographic Services ICSF Administrator&amp;apos;s Guide</cite>.</li>
<li>Search for TechDoc "Activation of Cryptographic Coprocessors and
Cryptographic Algorithms with ICSF, HCR7780", at <a href="./common-wwwsym.html">***</a>.</li></ul>
<h2 id="af1dfsm1">DFSMS migration
actions</h2>
<p>This topic describes migration actions for base element DFSMSdfp and
optional features DFSMSdss, DFSMShsm, DFSMSrmm,
and DFSMStvs.</p>
<h3 id="e0z3m100-gen108">DFSMS actions
to perform before installing z/OS V2R1</h3><a id="idx913"></a>
<p>This topic describes DFSMS migration actions that you can perform
on your current (old) system. You do not need the z/OS V2R1 level
of code to make these changes, and the changes do not require the
z/OS V2R1 level of code to run once they are made.</p>
<p><a href="e0z3m100.htm#ax3eisc1">DFSMSdfp:
Back up SMS control data sets</a></p>
<p><a href="e0z3m100.htm#dt2mg366">DFSMSdfp: Obtain descriptive text in messages for Open/Close/End
of Volume ABENDs</a></p>
<p><a href="e0z3m100.htm#listcsi">DFSMSdfp: Accommodate deletion of NOIMBED and
NOREPLICAT LISTCAT command attributes</a></p>
<p><a href="e0z3m100.htm#iggcat">DFSMSdfp: Define IGGCATxx parmlib member</a></p>
<p><a href="e0z3m100.htm#dfsmssms">DFSMS: Remove SMA fields from the SMS storage group construct
IGDSGD ands from ISMF panels</a></p>
<h4 id="ax3eisc1">DFSMSdfp:
Back up SMS control data sets</h4><a id="idx914"></a><a id="idx915"></a><a id="idx916"></a><a id="idx917"></a>
<p>[[[[ Technical contact: Stevan Steve Allen/San
Jose/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: In a multisystem Storage Management
Subsystem (SMS) complex, operating systems share a common set of SMS
classes, groups, ACS routines, and a configuration base, which make
up the storage management policy for the complex. This storage management
policy is maintained in a source control data set (SCDS). When this
policy is activated for SMS, the bound policy is maintained in processor
storage and on DASD in an active control data set (ACDS). Systems
in the complex communicate SMS information through a common communications
data set (COMMDS).</p>
<p><a id="idx918"></a><a id="idx919"></a><a id="idx920"></a><a id="idx921"></a><a id="idx922"></a><a id="idx923"></a><a id="idx924"></a><a id="idx925"></a><a id="idx926"></a><a id="idx927"></a>It is recommended that to successfully share SMS control data sets
in a multisystem environment where there are mixed levels of DFSMS, you update,
translate, validate, and activate SMS policies on the system with
the latest level of DFSMS.
When an earlier control data set is to be updated or activated, the
control data set is formatted by the later-level system. The shared
SMS control blocks reflect the new, rather than the previous, lengths
and control information.</p>
<p>For fallback, IBM recommends
restoring SMS control data sets from backups taken on the fallback
release.</p>
<p>Editing a policy on an earlier system could invalidate unused control
information and prevent the control data set from being accessed by
a later system.  A warning message is provided before a policy can
be changed on an earlier system. ACS routines may need to be updated
and translated so to not reference policy items not known to the earlier
system.</p>
<p>Remember, you risk policy activation failures if SCDS changes are
not validated using the latest-level system in a sysplex.</p>
<table id="wq499" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to ensure data integrity.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>Install the PTFs in <a href="e0z3m100.htm#coxptfs">Install coexistence and fallback PTFs</a> if
they are not already installed.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Do the following
on your pre-z/OS V1R13 systems:</p>
<ol type="1">
<li>Back up SMS control data sets according to established procedures
in the event that fallback is required. The control data set format
is VSAM linear.</li>
<li>Install all coexistence PTFs in <a href="e0z3m100.htm#coxptfs">Install coexistence and fallback PTFs</a>.</li></ol>
<p>In addition, if you modified and activated a higher-level
policy on a pre-z/OS V1R13 system, do the following to ensure
that the ACDS can be accessed on z/OS V1R13:</p>
<ol type="1">
<li> On the pre-z/OS V1R13 system, save the active ACDS as
an SCDS with the SETSMS SAVESCDS command.</li>
<li>On z/OS V1R13, update,
translate, validate, and activate the saved SMS policy.</li></ol>
<p><strong>Reference information</strong>: 

</p>
<ul>
<li><cite>z/OS DFSMS Implementing System-Managed Storage</cite></li>
<li><cite>z/OS DFSMSdfp Storage Administration</cite></li></ul>
<h4 id="dt2mg661">DFSMSdfp: Obtain descriptive text in messages for Open/Close/End
of Volume ABENDs</h4><a id="idx928"></a>
<p></p>
<p><strong>Description</strong>: z/OS V1R13 DFSMSdfp introduces a new
function that externalizes in the IECxxxx message for OPEN, CLOSE,
end-of-Volume determinant ABENDs,  the descriptive text from the message
documentation manuals.  This function is enabled by specifying in
the MPFLST<em>xx</em> PARMLIB member: MSGOPTION VERBOSE(x), where <em>x</em> is
either Y or N, with N as the default.  If you were using OCE_ABEND_DESCRIP
in DEVSUPxx to obtain this descriptive text before OA37505 was installed,
then you need to convert to using MPFLSTxx after OA37505 is installed.</p>
<div>
<div class="note-noindent" id="wq502">
<span class="notetitle">Note:</span> <span class="notebody">Beginning in z/OS V2R1, or after applying the PTF for
APAR OA37505 in z/OS V1R13, the VERBOSE message is displayed only
in the JOBLOG.</span></div></div>
<p>In addition, all OPEN, CLOSE and End-of-volume ABEND messages
are issued using a Message Buffer Manager service, whether or not
the new VERBOSE message function is enabled. One change this introduces
is that the IECxxxx portion of the message always appears as a multi-line
WTO message. Automated operation services that parse these messages
may be affected.</p>
<table id="wq503" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdfp</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13 with PTF for APAR OA37505 applied.</td>
</tr>
<tr id="dt2mg662">
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 without PTF for APAR OA37505 applied,
and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if any of these conditions are true:

<ul>
<li>You have z/OS V1R13 without APAR OA37505 installed, and are using
the OCE_ABEND_DESCRIP function in DEVSUPxx for verbose messages.</li>
<li>If you have automation or programs that depend upon the type (single-line
WTO as opposed to multi-line WTO) of the IECxxxx message.</li></ul></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>Remove OCE_ABEND_DESCRIP from DEVSUPxx parmlib
member; otherwise you receive the following informational message
at IPL time: 
<pre class="xmp"><code>IEA253I DEVSUP OCE_ABEND_DESCRIP 
NO LONGER HAS AFFECT. USE MPFLSTXX MEMBER </code></pre></td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If
you were using DEVSUP<em>xx</em> to obtain the ABEND descriptive text
before OA37505 was installed, then you need to convert to using MPFLST<em>xx</em> to
obtain this information after OA37505 is installed. In the MPFLST<em>xx</em> PARMLIB
member, specify MSGOPTION VERBOSE(Y) to enable display of the descriptive
text.</p>
<p>Because OPEN, CLOSE and end-of-volume ABEND messages now include
the IECxxxx portion of the message as a multi-line WTO message, any
automated operation services that parse these messages might need
to be adjusted. Examine such automated operation services and adjust
them to handle the new format as needed.</p>
<p>Here is an example of the output message you receive after you
install APAR OA37505: </p>
<pre class="xmp"><code>JOB00608 00000090 IEC141I 013-18,IGG0191B,IBMUSER9,S01,SYSUT1,5901,ZR1DT1, 651
651 00000090 SYS1.SAMPLIB(ZZZZZZZZ) </code></pre>
<p><strong>Reference information:</strong> For
details about using the VERBOSE option in MPFLSTxx, see <cite>z/OS MVS Initialization and Tuning Guide</cite>.</p>
<h4 id="listcsi">DFSMSdfp: Accommodate deletion of NOIMBED and
NOREPLICAT LISTCAT command attributes</h4>
<p>[[[[ Contributing writer: Kristine M
Logan/Poughkeepsie/IBM@IBMUS ]]]] [[[[ Technical contact: Elaine Lai/San
Jose/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13, output from the IDCAMS LISTCAT
command displayed the NOIMBED and NOREPLICAT attributes. Starting
with z/OS V1R13, these attributes are no longer included in the LISTCAT
command output. This might affect programs that parse LISTCAT results.</p>
<p>In 2001, support for creating data sets with IMBED or REPLICATE
attributes on the AMS DEFINE command was removed. Starting with z/OS
V1R13, the LISTCAT output no longer displays the default NOIMBED and
NOREPLICAT attributes. This information is no longer needed. This
might affect programs that parse LISTCAT results.</p>
<p>Note that for any cluster defined prior to 2001 with IMBED or REPLICATE
attributes, those attributes are displayed in IDCAMS LISTCAT command
output.</p>
<p>Before this z/OS V1R13 change, when you issued a LISTCAT
for a data set, at the end, you would see attribute characteristics.
They would look something like this example: </p>
<pre class="xmp"><code> ATTRIBUTES
  KEYLEN----------------15     AVGLRECL--------------80 
  RKP--------------------0     MAXLRECL--------------80 
  STRIPE-COUNT-----------1

  SHROPTNS(4,3)   RECOVERY     UNIQUE           NOERASE     INDEXED      NOWRITECHK     NOIMBED       NOREPLICAT
  UNORDERED        NOREUSE     NONSPANNED      EXTENDED     EXT-ADDR </code></pre>
<p>Starting with z/OS VR13, when you issue a LISTCAT for
a data set, the result will look something like this example: </p>
<pre class="xmp"><code>ATTRIBUTES
  KEYLEN----------------15     AVGLRECL--------------80 
  RKP--------------------0     MAXLRECL--------------80 
  STRIPE-COUNT-----------1

  SHROPTNS(4,3)   RECOVERY     UNIQUE           NOERASE     INDEXED      NOWRITECHK    UNORDERED      NOREUSE
  NONSPANNED      EXTENDED     EXT-ADDR </code></pre>
<p><a id="idx929"></a></p>
<table id="wq504" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td> DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if you use programs that
parse LISTCAT results.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: It is recommended that you convert the programs
that parse LISTCAT results to use Catalog Search Interface (CSI).</p>
<p><strong>Reference information</strong>: See information about CSI in <cite>z/OS DFSMS Managing Catalogs</cite>.</p>
<h4 id="iggcat">DFSMSdfp: Define IGGCATxx parmlib member</h4>
<p>[[[[ Contributing writer: &lt;Example,
Kristine Logan - klogan@us.ibm.com &gt; ]]]] [[[[ Technical contact: &lt;Example:
Rohan Kurane - Rohan Kurane/Silicon Valley/IBM,  &gt; ]]]]</p>
<p><strong>Description</strong>: Starting with z/OS V1R13, if you do
not use an IGGCATxx parmlib member for catalog parameters, you might
receive system message IEA301I IGGCAT00 NOT FOUND IN PARMLIB. If you
are using a single parmlib data set like SYS1.PARMLIB, message IEA301I
is displayed with the following text: IGGCAT00 NOT FOUND IN SYS1.PARMLIB.</p>
<p><a id="idx930"></a></p>
<table id="wq505" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMSdfp</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to avoid message IEA301I
referencing missing parmlib member IGGCATxx.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Do one of the following to define parmlib
member IGGCATxx to your system before IPLing V1R13 to prevent system
message IEA301I referencing missing parmlib member IGGCATxx: 
</p>
<ul>
<li>Create member IGGCAT00 in SYS1.PARMLIB or concatenation. Because
IGGCAT00 is the default, you do not have to specify <samp class="xph">00</samp> on
the CATALOG= parameter in parmlib member IEASYSxx.</li>
<li>Create IGGCATxx member(s) in SYS1.PARMLIB or concatenation. Specify
one or more members on the CATALOG= parameter of IEASYSxx so that
the system will search for and parse the specified members.</li></ul><p class="indatacontent">If you wish to take the default values set up for IGGCATxx, you
do not have to specify any parameters in the IGGCATxx member(s). The
system will find the member or members, and use the default parameter
values if none are specified in IGGCATxx.</p>
<p><strong>Reference information</strong>: For details about the IGGCATxx parmlib
member, see <cite>z/OS MVS Initialization and Tuning Reference</cite>.</p>
<h4 id="dt2mg663">DFSMS: Remove SMA fields from the SMS storage group construct
IGDSGD ands from ISMF panels</h4><a id="idx931"></a><a id="idx932"></a>
<p>[[[[ Contributing writer: /IBM@IBMUS ]]]]
[[[[ Original technical contact: ]]]]</p>
<p>To be updated in the next review.</p>
<p><strong>Description</strong>: Before z/OS V1R13, new SMS storage group constructs
were created in DFSMS in support of the z/OSMF DASD Management task.
Starting with z/OS V1R13 the DASD Management task has been removed
from z/OSMF, and these fields (known as SMA attributes) will be removed
from the storage group construct (IGDSGD). The fields have been removed
from ISMF panels, Naviquest APIs, and DCOLLECT records.</p>
<table id="wq506" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMS</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13 with APAR PM40869 applied. See Software
Announcement 211-252 (RFA56143).</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS z/OS V1R13 and z/OS V1R12 without APAR
PM40869 applied.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td align="left">Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you parse the new attributes in DCOLLECT
output or view/update them through NAVIQUEST. IBM might redefine these
storage group and DCOLLECT fields in a future release.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>z/OS V1R13</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ol type="1">
<li>Look for the following storage group attributes (known as SMA
attributes) as defined by the IGDSGD macro. 

<ul>
<li>SGDMANTH</li>
<li>SGDMASUG</li>
<li>SGDMAMAX</li>
<li>SGDMAVSZ</li>
<li>SGDMAVTC</li>
<li>SGDMARSP</li>
<li>SGDMAVNM</li></ul></li>
<li>Identify the following Naviquest functions associated with the
SMA attributes identified in step 1.: 

<ul>
<li>ACBQBAJ2 - clist for Define/Alter/Display pool storage group</li>
<li>ACBQBAJG - clist for Pool Storage Group Display ACBJBAJ2 -</li>
<li>Sample JCL for Pool storage group define/alter/display</li>
<li></li></ul></li>
<li>Use the IDCDOUT mapping macro to map the following DCOLLECT fields
and remove the references to those fields: 

<ul>
<li>DSGFSMA</li>
<li>DSGMANTH</li>
<li>DSGMASUG</li>
<li>DSGMAMAX</li>
<li>DSGMAVSZ</li>
<li>DSGMAVTC</li>
<li>DSGMARSP</li>
<li>DSGMAVNM</li></ul></li></ol>
<p><strong>Reference information:</strong> For information about the SMA attributes,
see the following:
</p>
<ul>
<li><cite>z/OS DFSMS Using the New Functions</cite></li>
<li><cite>z/OS DFSMSdfp Storage Administration</cite></li>
<li><cite>z/OS DFSMS Access Method Services Commands</cite></li></ul>
<h3 id="e0z3m100-gen109">DFSMS actions
to perform before the first IPL of z/OS V2R1</h3>
<p>This topic describes DFSMS migration actions that you can perform
after you have installed z/OS V2R1
but before the first time you IPL. These actions might require the z/OS V2R1 level of code to be installed
but do not require it to be active.</p>
<p><a href="e0z3m100.htm#af32b1">DFSMSdfp:
Ensure that the Language
Environment runtime library is available for DLLs******TO BE
REMOVED PER DISCUSSION ON EREVIEW**********</a></p>
<p><a href="e0z3m100.htm#af32e">DFSMSdfp:
Update SYS1.IMAGELIB</a></p>
<p><a href="e0z3m100.htm#iebcopy1">Examine and update program calls to IEBCOPY</a></p>
<p><a href="e0z3m100.htm#dadsmpro">	DFSMSdfp: Update operator procedures and system automation
for new DADSM pre- and post-processing dynamic exits</a></p>
<p><a href="e0z3m100.htm#dfpcopy">	DFSMSdfp: Update procedures that use IEBDSCPY alias name to
access IEBCOPY</a></p>
<p><a href="e0z3m100.htm#dt2mg366">DFSMSdfp: Obtain descriptive text in messages for Open/Close/End
of Volume ABENDs</a></p>
<p><a href="e0z3m100.htm#af3d">DFSMSdss:
Build the IPLable stand-alone DFSMSdss image</a></p>
<p><a href="e0z3m100.htm#csichng">DFSMSdss: Accommodate Catalog Search Interface default change</a></p>
<p><a href="e0z3m100.htm#hsmlist1">DFSMShsm: Update applications that depend on LIST command output</a></p>
<p><a href="e0z3m100.htm#hsmpdatr">DFSMShsm: Accommodate the changed default of PDA trace during
DFSMShsm startup</a></p>
<p><a href="e0z3m100.htm#hsmdsrec">DFSMShsm: Accommodate the changed SETSYS FASTREPLICATION command
DATASETRECOVERY parameter default</a></p>
<p><a href="e0z3m100.htm#hsmarc180">DFSMShsm: Replace user-defined patch with new SETSYS FASTREPLICATION
command to enable ARC1809I messages</a></p>
<p><a href="e0z3m100.htm#hsmmsgie">DFSMShsm: Review messages changed from I (informational) to
E (eventual action) type</a></p>
<p><a href="e0z3m100.htm#ptchmcvt">DFSMShsm: Remove patch that prevents SMS MVT chain rebuild</a></p>
<p><a href="e0z3m100.htm#hsmarccat">DFSMShsm: Stop using the HOLD command to quiesce activity prior
to control data set backup</a></p>
<p><a href="e0z3m100.htm#dt2mg377">DFSMSrmm: Check how you control your RACF tape profile processing</a></p>
<h4 id="af32b1">DFSMSdfp:
Ensure that the Language
Environment runtime library is available for DLLs******TO BE
REMOVED PER DISCUSSION ON EREVIEW**********</h4><a id="idx933"></a><a id="idx934"></a><a id="idx935"></a><a id="idx936"></a><a id="idx937"></a><a id="idx938"></a>
<p><strong>Description</strong>: Language
Environment provides common services and language-specific routines
in a single runtime environment. You can use Language Environment to build
and use dynamic link libraries (DLLs) for applications.<a id="idx939"></a><a id="idx940"></a></p>
<table id="wq508" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your installation builds or references
DLLs.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If your installation builds or references
DLLs, either you must set up the system link list to refer to the Language Environment runtime
libraries (SCEERUN and SCEERUN2), or each job that creates or uses
a DLL must include a STEPLIB DD statement referencing these libraries.</p>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li><cite>z/OS Language Environment Runtime Application Migration Guide</cite></li>
<li><cite>z/OS Language Environment Customization</cite></li>
<li><cite>z/OS Language Environment Programming Guide</cite></li></ul>
<h4 id="dt2mg673">DFSMSdfp:
Update SYS1.IMAGELIB</h4>
<p><strong>Description</strong>: If you use page mode printers
such as the IBM 3800 or the IBM 3900 running in line mode (not
page mode), you must install library character sets, graphic character
modification modules, and character arrangement tables in SYS1.IMAGELIB. <a id="idx941"></a><a id="idx942"></a><a id="idx943"></a>
This migration action does not
apply if you are using IBM 3900
printers that are driven by PSF.</p>
<table id="wq509" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are not using your old SYS1.IMAGELIB,
you are installing with ServerPac or SystemPac, and you are using line mode printers
such as the 3800 or 3900.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>IBM 3800
or 3900 printers.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Run the LCSBLD1 job from the samplib data set to create character
sets, graphic character modification modules, and character arrangement
tables in SYS1.IMAGELIB.</li>
<li>Copy customized or locally-written FCBs and UCS images from your
old system's SYS1.IMAGELIB data set to the new system's SYS1.IMAGELIB
data set.</li></ol>
<p><strong>Reference information</strong>: For information about
maintaining SYS1.IMAGELIB, see <cite>z/OS DFSMSdfp Advanced Services</cite>.</p>
<h4 id="dt2mg674">Examine and update program calls to IEBCOPY</h4><a id="idx944"></a>
<p>[[[[ Contributing writer: Paul F Gorgen/Poughkeepsie/IBM@IBMUS &gt;
]]]] [[[[ Technical contact: &lt;Example: Wayne Rhoten/San Jose/IBM@IBMUS &gt;
]]]]</p>
<p><strong>Description</strong>: Before z/OS V2R1, the IEBCOPY utility assumed
that calls from programs (not from JCL) that passed three parameters,
had the high order bit set on in the third word of the parameter list.
Starting in z/OS V2R1, IEBCOPY requires the high order bit to be on
in the third word of a parameter list; if that bit is not on, IEBCOPY
causes a failure. This change can affect your programs that call IEBCOPY,
requiring you to update them if needed. <a id="idx945"></a></p>
<p>Beginning in z/OS V2R1, the invoker of IEBCOPY will be
able to specify the exits by using the fourth parameter on the invocation.
The new fourth word in the IEBCOPY invocation parameter list has a
31-bit address of the user exit parameter list. This IEBCOPY user
exit routine enables a program to supply IEBCOPY control statements
instead of IEBCOPY reading control statements from SYSIN.</p>
<table id="wq511" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and DFSMS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have programs that pass
a parameter list of exactly three words to IEBCOPY and do not set
on the high order bit in the last word.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Examine calls from programs (not from JCL)
to IEBCOPY, to see whether any pass three parameters  without turning
on the high order bit in the last word.  If you have such programs,
revise them to turn on the high order bit of the last word of the
parameter list. If you are using the CALL, LINK or ATTACH macro, the
simplest way to do this is to add the VL parameter to CALL or VL=1
parameter to LINK or ATTACH.</p>
<p><strong>Reference information</strong>: For details about program calls to
IEBCOPY, see <cite>z/OS DFSMSdfp Utilities</cite>.</p>
<h4 id="dadsmpro">	DFSMSdfp: Update operator procedures and system automation
for new DADSM pre- and post-processing dynamic exits</h4><a id="idx946"></a><a id="idx947"></a><a id="idx948"></a><a id="idx949"></a>
<p>[[[[ Contributing writer: Paul F Gorgen/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: James Cammarata/Chicago/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13, exits for the DADSM pre-
and post-processing functions were loaded by DFSMSdfp, as installation
exits during initialization, as modules IGGPRE00 and IGGPOST0.  Starting
with z/OS V1R13,  z/OS dynamic exits services is used to define a
pre-processing dynamic exit,  IGGPRE00_EXIT, and a post-processing
dynamic exit, IGGPOST0_EXIT, and  associate IGGPRE00 and IGGPOST0
modules as exit routines to these respective dynamic exits. All DADSM
functions (create, extend, scratch, partial release, and rename) share
these common dynamic exits and will be called where the previous installation
exits of IGGPRE00 and IGGPOST0 were called using the same existing
interfaces.  This change requires changes to DFSMSdfp operating procedures
and system automation (if any).<a id="idx950"></a></p>
<table id="wq512" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if DADSM installation exits IGGPRE00 or
IGGPOST0 are in use.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ul>
<li>If you use the IGGPRE00 or the IGGPOST0 installation exits, you
do not need to change them  in any way; just install them as you always
have. DFSMSdfp will automatically exploit the dynamic exit services
and use your IGGPRE00 or IGGPOST0 installation exit as exit routines
to the new IGGPRE00_EXIT and IGGPOST0_EXIT dynamic exits.  You do
not need to change the load module names for IGGPRE00 or IGGPOST0,
however, you may change the names if desired. If you do change the
names, update the PROG<em>xx</em> parmlib member or issue the <span class="synph"><span class="kwd">SETPROG</span></span> command
to get the modules loaded because DFSMSdfp will not load them as exit
routines to the dynamic exits.</li>
<li>You can now have multiple exit routines associated with each of
the IGGPRE00_EXIT and  IGGPOST0_EXIT dynamic exits for the DADSM pre-
and post-processing exits.  Other programs can use the CSVDYNEX macro
to associate their exit routines to these dynamic exits and can add
and delete exit routines from any dynamic exit routine as required.
They also can be added and deleted with the PROG<em>xx</em> member of
parmlib and with the SETPROG ADD operator command.  All exit routines
will be called when the DADSM pre- and post-dynamic exits are called
from each DADSM function.  The execution of one exit routine may then
change the behavior of a subsequent one. The order in which the exit
routines are called by the system could be in any order.</li>
<li>The IGGPRE00 and IGGPOST0 module addresses in the CVAF table (CVFDPR31,
CVFDPOR31) will continue to be set. Therefore, other programs that
continue to use this interface will be unaffected.  Since dynamic
exit services would not be used in this case, no other exit routine
associated with the dynamic exits will be called. These programs should
be changed to use dynamic exit services, CSVDYNEX.</li></ul>
<p><strong>Reference information</strong>: To read more about the use of dynamic
exit services and these new dynamic exits, see:  
</p>
<ul>
<li> <cite>z/OS MVS Programming: Authorized Assembler
Services Guide</cite> for
information about the CSVDYNEX macro.</li>
<li> <cite>z/OS MVS Initialization and Tuning Reference</cite> for
information about the PROG<span class="synph"><span class="var">xx</span></span> parmlib member.</li>
<li> <cite>z/OS MVS System Commands</cite> for
information about the <span class="synph"><span class="kwd">D PROG</span></span>, <span class="synph"><span class="kwd">SETPROG
EXIT</span></span>, and <span class="synph"><span class="kwd">SET PROG=</span></span><span class="synph"><span class="var">xx</span></span> commands.</li>
<li><cite>z/OS DFSMS Installation Exits</cite>,
"DFSMS Data Management Installation/Dynamic Exits" chapter.</li></ul>
<h4 id="dfpcopy">	DFSMSdfp: Update procedures that use IEBDSCPY alias name to
access IEBCOPY</h4>
<p>[[[[ Contributing writer: Paul F Gorgen/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Tom Mahon/San Jose/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13, the IEBCOPY utility was
an APF-authorized program that had to run from an APF-authorized library.
If another program called IEBCOPY, that program also had to be APF-authorized.
Starting in z/OS V1R13, the IEBCOPY utility is no longer APF-authorized
and can be run from non-authorized libraries; callers of IEBCOPY no
longer need to be APF-authorized. In addition to this authorization
change, other performance improvements have been made to IEBCOPY as
well.</p>
<p>IEBCOPY is a data set library management utility that is used to
perform many critical system build and maintenance activities. If
this utility does not work correctly, then key library data sets could
be rendered as unusable and the z/OS user would be left without a
fallback method. A fallback copy of the z/OS V1R12 level of IEBCOPY
is provided, named IEBCOPYO, for use if you experience problems with
the updated version of IEBCOPY in z/OS V1R13.  The old IEBCOPYO utility
with its alias of IEBDSCPY is installed into SYS1.LINKLIB with authorization
code one, AC(1). <a id="idx951"></a></p>
<p>Since the code in IEBCOPY is now different from the code in IEBCOPYO,
IBM recommends that you do not copy and replace IEBCOPY with IEBCOPYO
because of maintenance issues. <span>PTFs will update IEBCOPY
and IEBCOPYO load modules appropriately as each load module requires
service.</span></p>
<p>The IEBDSCPY alias name of IEBCOPY that exists in earlier versions
of DFSMS is no longer an alias name in the z/OS DFSMS V1R13 IEBCOPY
load module. The IEBDSCPY alias name continues to exist as the alias
to the IEBCOPYO load module in z/OS V1R13, but will be eliminated
as an alias of the IEBCOPYO load module in future releases of DFSMS.
 If you currently access the IEBCOPY utility by using the IEBDSCPY
alias name, you need to make the necessary change to use the IEBCOPY
primary name.</p>
<table id="wq513" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but reommended if you don't want to be connected
to the pre-z/OS V1R13 version of IEBCOPY.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>It is important to note with the changes introduced
in z/OS V1R13 IEBCOPY, the requirement for SMP/E to be APF-authorized
remains. That is, these IEBCOPY changes have no effect on the requirement
that SMP/E is APF-authorized.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ul>
<li>Programs or procedures that use the IEBDSCPY alias name to access
IEBCOPY should be changed to use the IEBCOPY primary name. Programs
that continue to use the alias name will connect to the old, pre-z/OS
V1R13 version, currently called IEBCOPYO.</li>
<li>IEBCOPY can now be called by programs that are not APF-authorized.</li></ul>
<p><strong>Reference information</strong>: For more information about the IEBCOPY
utility, see <cite>z/OS DFSMSdfp Utilities</cite>.</p>
<h4 id="dt2mg675">DFSMSdfp: Obtain descriptive text in messages for Open/Close/End
of Volume ABENDs</h4><a id="idx952"></a>
<p></p>
<p><strong>Description</strong>: z/OS V1R13 DFSMSdfp introduces a new
function that externalizes in the IECxxxx message for OPEN, CLOSE,
end-of-Volume determinant ABENDs,  the descriptive text from the message
documentation manuals.  This function is enabled by specifying in
the MPFLST<em>xx</em> PARMLIB member: MSGOPTION VERBOSE(x), where <em>x</em> is
either Y or N, with N as the default.  If you were using OCE_ABEND_DESCRIP
in DEVSUPxx to obtain this descriptive text before OA37505 was installed,
then you need to convert to using MPFLSTxx after OA37505 is installed.</p>
<div>
<div class="note-noindent" id="wq514">
<span class="notetitle">Note:</span> <span class="notebody">Beginning in z/OS V2R1, or after applying the PTF for
APAR OA37505 in z/OS V1R13, the VERBOSE message is displayed only
in the JOBLOG.</span></div></div>
<p>In addition, all OPEN, CLOSE and End-of-volume ABEND messages
are issued using a Message Buffer Manager service, whether or not
the new VERBOSE message function is enabled. One change this introduces
is that the IECxxxx portion of the message always appears as a multi-line
WTO message. Automated operation services that parse these messages
may be affected.</p>
<table id="wq515" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSdfp</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V1R13 with PTF for APAR OA37505 applied.</td>
</tr>
<tr id="dt2mg676">
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 without PTF for APAR OA37505 applied,
and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if any of these conditions are true:

<ul>
<li>You have z/OS V1R13 without APAR OA37505 installed, and are using
the OCE_ABEND_DESCRIP function in DEVSUPxx for verbose messages.</li>
<li>If you have automation or programs that depend upon the type (single-line
WTO as opposed to multi-line WTO) of the IECxxxx message.</li></ul></td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>Remove OCE_ABEND_DESCRIP from DEVSUPxx parmlib
member; otherwise you receive the following informational message
at IPL time: 
<pre class="xmp"><code>IEA253I DEVSUP OCE_ABEND_DESCRIP 
NO LONGER HAS AFFECT. USE MPFLSTXX MEMBER </code></pre></td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If
you were using DEVSUP<em>xx</em> to obtain the ABEND descriptive text
before OA37505 was installed, then you need to convert to using MPFLST<em>xx</em> to
obtain this information after OA37505 is installed. In the MPFLST<em>xx</em> PARMLIB
member, specify MSGOPTION VERBOSE(Y) to enable display of the descriptive
text.</p>
<p>Because OPEN, CLOSE and end-of-volume ABEND messages now include
the IECxxxx portion of the message as a multi-line WTO message, any
automated operation services that parse these messages might need
to be adjusted. Examine such automated operation services and adjust
them to handle the new format as needed.</p>
<p>Here is an example of the output message you receive after you
install APAR OA37505: </p>
<pre class="xmp"><code>JOB00608 00000090 IEC141I 013-18,IGG0191B,IBMUSER9,S01,SYSUT1,5901,ZR1DT1, 651
651 00000090 SYS1.SAMPLIB(ZZZZZZZZ) </code></pre>
<p><strong>Reference information:</strong> For
details about using the VERBOSE option in MPFLSTxx, see <cite>z/OS MVS Initialization and Tuning Guide</cite>.</p>
<h4 id="dt2mg677">DFSMSdss:
Build the IPLable stand-alone DFSMSdss image</h4>
<p>[[[[ Techical contact: Robert2 Gensler/Tucson/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: If you intend to use the Stand-Alone
Services provided by DFSMSdss, you must use the DFSMSdss BUILDSA
function to create the Stand-Alone Services IPL-capable core image. Starting
with z/OS V1R12, DFSMSdss now uses BSAM instead of EXCP to read from
and write to DFSMSdss dump data sets during DUMP, COPYDUMP, and RESTORE
operations. To migrate to this support, you must rebuild the IPL-able
core image for the Stand-Alone Services program. <a id="idx953"></a><a id="idx954"></a></p>
<p>If this migration
action is not performed, users of the DSS standalone restore will
not be able to restore backups on tape created with greater than 65520
byte blocks. Message ADRY3530I SEQUENCE ERROR ON RESTORE TAPE is issued
and the operation is terminated. Backups created with 65520 byte blocks
will restore as they did in z/OS V1R11.</p>
<table id="wq516" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMSdss.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you intend to use the Stand-Alone Services
provided by DFSMSdss.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>Stand-Alone Services supports the IBM 3494 TotalStorage Enterprise Automated Tape Library,
the IBM 3495 TotalStorage Enterprise
Automated Tape Library, and the IBM 3590 TotalStorage Enterprise
Tape Subsystem.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>Stand-Alone Services does not support the creation
of the core image on an SMS-managed volume.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>
<ul>
<li>To ensure that Stand-Alone Services is available when you run
from DASD, do not delete the SYS1.ADR.SAIPLD.Vvolser data set or move
it to another volume.</li>
<li>If you IPL from DASD and later change the volume serial number,
you must rerun the BUILDSA function to create a new core image data
set with the new volume serial number in the name.</li></ul></td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Prepare for Stand-Alone Services by creating a Stand-Alone Services
IPLable core image with the BUILDSA command. With the BUILDSA command
you can specify the device (card reader, tape drive, or DASD volume)
from which Stand-Alone Services will be IPLed. You can also specify
the operator console to be used for Stand-Alone Services. 


<p>The BUILDSA
function builds the IPLable core image under the current operating
system and determines a record size based on whether the IPL is from
card, tape, or DASD.</p></li>
<li>Use RACF or another external
security system to protect the SYS1.ADR.SAIPLD.V<span class="synph"><span class="var">volser</span></span> data
set and the Stand-Alone Services modules.</li>
<li>If you have not done so already, make a backup copy of your system
that can be restored by this function. For information about backing
up volumes, see <cite>z/OS DFSMSdss Storage Administration</cite>.

<div>
<div class="note-noindent" id="wq518">
<span class="notetitle">Note:</span> <span class="notebody">Message  ADRY3530I SEQUENCE ERROR ON RESTORE TAPE might
be issued with operation terminated if a user tries to restore a back
up that was created with a block size greater than 65520 bytes, using
the DSS stand-alone restore program from z/OS V1R11.</span></div></div></li></ol>
<p><strong>Reference information</strong>: For more information,
see <cite>z/OS DFSMSdfp Storage Administration</cite>.</p>
<h4 id="csichng">DFSMSdss: Accommodate Catalog Search Interface default change</h4>
<p>[[[[ Contributing writer: Shigeki Kimura/Japan/IBM@IBMJP
]]]] [[[[ Technical contact: Andrew N Wilt/Tucson/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: In z/OS V1R11, DFSMSdss logical data set COPY,
DUMP, and RELEASE operation used the Catalog Search Interface (CSI)
by default to find cataloged data sets based on the generic filter
criteria on the INCLUDE keyword when no input volumes are specified.
Before z/OS V1R11, you could make use of CSI functionality on z/OS
V1R10, z/OS V1R9, and z/OS V1R8 systems by installing the PTF for
APAR OA25644 and patching the offset X'54' into the ADRPATCH module
to X'11'.</p>
<p>In z/OS V1R13 (and with the PTF for APAR OA32120 installed on z/OS
V1R12), DFSMSdss no longer uses the CSI for Catalog filtering during
logical data set processing as the default; DFSMSdss uses generic
catalog locates in this scenario.<a id="idx955"></a><a id="idx956"></a><a id="idx957"></a></p>
<p></p>
<table id="wq519" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMSdss.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12 with APAR OA32120
applied.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12 without the PTF for APAR OA32120
applied.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to use CSI during Catalog filtering
for logical data set processing.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ul>
<li>To use the CSI during Catalog filtering for the DFSMSdss logical
data set COPY, DUMP, and RELEASE operation, the DFSMSdss patch byte
at offset X'54' must be set to X'11' to enable the functionality.</li>
<li>If the DFSMSdss patch byte at offset X'54' is set to any value
other than X'00' and X'11' to use generic catalog locates instead
of CSI (as done in earlier releases), you do not need to set it because
this previous method of finding cataloged data sets is now in effect
by default.</li></ul><p class="indatacontent"> </p>
<div>
<div class="note-noindent" id="wq520">
<span class="notetitle">Note:</span> <span class="notebody">If you are intentionally using the CSI default by setting
the DFSMSdss PATCH byte at offset X'54' to X'11', then you don't need
to take any action to expect the functionality be effective. However,
if you left the DFSMSdss PATCH byte at offset X'54' as X'00' and want
to continue using the CSI during Logical Data Set processing, you
need to set that Patch byte to X'11'.</span></div></div>
<p><strong>Reference information</strong>: For more information about the DFSMSdss
patch byte, see  
</p>
<ul>
<li>INFO APAR II14616.</li>
<li><cite>z/OS DFSMSdss Storage Administration</cite>.</li></ul>
<h4 id="hsmlist1">DFSMShsm: Update applications that depend on LIST command output</h4>
<p>[[[[ Contributing writer: Bill Keller]]]]
[[[[ Technical contact: Jason R. Luurs]]]]</p>
<p><strong>Description</strong>: The output of the LIST DUMPCLASS command now
includes the value of the RECOVERRESET parameter. 	RECOVERRESET is
a new parameter of the DEFINE DUMPCLASS command that specifies whether
or not the data-set-changed indicator in the VTOC entry is reset for
all data sets that are restored during full volume recover processing.<a id="idx958"></a><a id="idx959"></a></p>
<table id="wq521" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMShsm</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your application depends on the output
of the LIST DUMPCLASS command.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Update applications that depend on the output
of the LIST DUMPCLASS command to accommodate the new value for RECOVERRESET.</p>
<p><strong>Reference information</strong>: For details about the LIST DUMPCLASS
output, refer to <cite>z/OS DFSMShsm Storage Administration</cite>.</p>
<h4 id="hsmpdatr">DFSMShsm: Accommodate the changed default of PDA trace during
DFSMShsm startup</h4>
<p>[[[[ Contributing writer: Michael Forte/Poughkeepsie/IBM
]]]] [[[[ Technical contact: Shannon L Gallaher/Tucson/IBM, Glenn
Wilcock/Tucson/IBM ]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13, PDA trace was disabled (PDA=NO)
during DFSMShsm startup unless PDA=YES was <em>manually</em> added to
the DFSMShsm startup procedure. Starting with z/OS V1R13, PDA trace
is enabled (PDA=YES) by default during DFSMShsm startup. After DFSMShsm
is started, the SETSYS PDA setting controls PDA tracing.<a id="idx960"></a><a id="idx961"></a><a id="idx962"></a><a id="idx963"></a></p>
<table id="wq522" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMShsm.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you do not want the new default.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: To enable PDA trace during DFSMShsm startup,
no action is required. To disable PDA trace during DFSMShsm startup,
specify PDA=NO in the DFSMShsm startup procedure before starting DFSMShsm.</p>
<div>
<div class="note-noindent" id="wq523">
<span class="notetitle">Note:</span> <span class="notebody">When you do not allocate the ARCPDOX and ARCPDOY data sets in
the DFSMShsm start procedure, you receive the following message during
initialization unless PDA=NO is explicitly specified.  
<pre class="xmp"><code>ARC0036E I/O [INHIBITED | DISABLED] FOR DFSMSHSM PROBLEM DETERMINATION 
  OUTPUT DATA SET, REAS=<span class="synph"><span class="var">reason-code</span></span></code></pre> Even
in this situation, HSM continues to initialize and operate.</span></div></div>
<p><strong>Reference information</strong>: For more information about enabling
or disabling PDA trace during DFSMShsm startup, see <cite>z/OS DFSMShsm Implementation and Customization Guide</cite>.</p>
<h4 id="hsmdsrec">DFSMShsm: Accommodate the changed SETSYS FASTREPLICATION command
DATASETRECOVERY parameter default</h4>
<p>[[[[ Contributing writer: Michael Forte/Poughkeepsie/IBM
]]]] [[[[ Technical contact: Yufen Davis/Tucson/IBM, Glenn Wilcock/Tucson/IBM
]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13, the <span class="synph"><span class="kwd">SETSYS FASTREPLICATION</span></span> command
DATASETRECOVERY parameter default was PREFERRED and fast replication
data set recovery was performed whenever possible. The standard copy
method was used when fast replication could not be. Starting with
z/OS V1R13, the <span class="synph"><span class="kwd">SETSYS FASTREPLICATION</span></span> command
DATASETRECOVERY parameter default is changed to NONE and the standard
copy method is used to perform data set recovery. Fast replication
is not used by default.<a id="idx964"></a><a id="idx965"></a><a id="idx966"></a><a id="idx967"></a><a id="idx968"></a><a id="idx969"></a><a id="idx970"></a><a id="idx971"></a><a id="idx972"></a></p>
<table id="wq524" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMShsm.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to use fast replication for
data set recovery and you do not currently specify a fast replication
data set recovery preference in the ARCCMD<em>xx</em> parmlib member
of SYS1.PARMLIB.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Determine which fast replication data set recovery preference
you want to use.</li>
<li>Add a fast replication data set recovery preference to the ARCCMD<em>xx</em> parmlib
member of SYS1.PARMLIB. 

<ul>
<li>If a fast replication data set recovery preference is specified
and matches the preference you want to use, no action is required.</li>
<li>If no fast replication data set recovery preference is specified,
add <span class="synph"><span class="kwd">SETSYS FASTREPLICATION (DATASETRECOVERY (PREFERRED))</span></span> to
continue using the same preference as before z/OS V1R13.</li></ul>Alternatively, if your preference is to require fast replication
data set recovery, you can specify <span class="synph"><span class="kwd">SETSYS FASTREPLICATION
(DATASETRECOVERY (REQUIRED))</span></span>.</li></ol>
<p> </p>
<div>
<div class="note-noindent" id="wq526">
<span class="notetitle">Note:</span> <span class="notebody">
<ol type="1">
<li>If you previously specified <span class="synph"><span class="kwd">SETSYS FASTREPLICATION
(DATASETRECOVERY (NONE))</span></span> in the ARCCMD<em>xx</em> parmlib
member of SYS1.PARMLIB, you can optionally remove it and use the default.</li>
<li>The<span class="synph"><span class="kwd"> FRRECOV</span></span> command ALLOWPPRCP options
PRESERVEMIRRORREQUIRED, PRESERVEMIRRORPREFERRED, PRESERVEMIRRORNO,
and YES cannot be used if fast replication data set recovery is not
allowed, that is, if the z/OS V1R13 <span class="synph"><span class="kwd">SETSYS FASTREPLICATION</span></span> command
DATASETRECOVERY parameter default is used or if <span class="synph"><span class="kwd">SETSYS
FASTREPLICATION (DATASETRECOVERY (NONE))</span></span> setting is
in effect.</li></ol></span></div></div>
<p><strong>Reference information</strong>: For more information about fast replication,
the <span class="synph"><span class="kwd">FRRECOV</span></span> command, and the <span class="synph"><span class="kwd">SETSYS</span></span> command,
see <cite>z/OS DFSMShsm Storage Administration</cite>.</p>
<h4 id="hsmarc180">DFSMShsm: Replace user-defined patch with new SETSYS FASTREPLICATION
command to enable ARC1809I messages</h4>
<p>[[[[ Contributing writer: Michael Forte/Poughkeepsie/IBM
]]]] [[[[ Technical contact: Shannon L Gallaher/Tucson/IBM, Glenn
Wilcock/Tucson/IBM ]]]]</p>
<p><strong>Description</strong>: <span>Before z/OS V1R13, a patch was
required to enable (and subsequently disable) ARC1809I messages during
fast replication volume pairing. Starting with z/OS V1R13, the VOLUMEPAIRMESSAGES
parameter is added to the existing <span class="synph"><span class="kwd">SETSYS FASTREPLICATION</span></span> command
to control the issuance of the ARC1809I messages. Remove the patch
and replace it with the new parameter.</span> <a id="idx973"></a><a id="idx974"></a><a id="idx975"></a><a id="idx976"></a><a id="idx977"></a><a id="idx978"></a><a id="idx979"></a></p>
<table id="wq528" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMShsm.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the ARCCMD<em>xx</em> parmlib member of
SYS1.PARMLIB contains: <samp class="xph">PATCH .FRGCB.+9 BITS(.1......)</samp></td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td> 
<div class="lines">The <span class="synph"><span class="kwd">SETSYS FASTREPLICATION</span></span><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="synph"><span class="kwd">(VOLUMEPAIRMESSAGES(YES))</span></span><br />
statement in ARCCMD<span class="synph"><span class="var">xx</span></span> is not supported<br />
on pre-z/OS V1R13 systems.<br />
</div></td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Remove <samp class="xph">PATCH .FRGCB.+9 BITS(.1......)</samp> from the
ARCCMD<em>xx</em> parmlib member of SYS1.PARMLIB.</li>
<li>Add <span class="synph"><span class="kwd">SETSYS FASTREPLICATION(VOLUMEPAIRMESSAGES(YES))</span></span> to
the ARCCMD<em>xx</em> parmlib member of SYS1.PARMLIB.</li></ol>
<p><strong>Reference information</strong>: For more information about using
the <span class="synph"><span class="kwd">SETSYS FASTREPLICATION</span></span> command and VOLUMEPAIRMESSAGES
parameter to disable unwanted ARC1809I messages, see <cite>z/OS DFSMShsm Storage Administration</cite>.</p>
<h4 id="hsmmsgie">DFSMShsm: Review messages changed from I (informational) to
E (eventual action) type</h4>
<p>[[[[ Contributing writer: Michael Forte/Poughkeepsie/IBM
]]]] [[[[ Technical contact: Kirk Affolder/Tucson/IBM, Glenn Wilcock/Tucson/IBM
]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13, messages ARC0036, ARC0503,
and ARC0704 were <em>informational</em> messages (ending in the letter &quot;I&quot;).
Starting with z/OS V1R13, messages ARC0036, ARC0503, and ARC0704 are
reclassified as <em>eventual action</em> messages (ending in the letter &quot;E&quot;).
The meaning of the messages is unchanged. The type is changed only.</p>
<p>Each of these messages indicate a significant error has occurred
and are more easily identifiable as eventual action messages. 
</p>
<ul>
<li>Message ARC0036E indicates that an I/O error occurred when writing
to the PDA output data set.</li>
<li>Message ARC0503E indicates a dynamic allocation error.</li>
<li>Message ARC0704E indicates a VTOC copy data set processing error
during volume backup, dump, or recovery.</li></ul><p class="indatacontent">These changes can affect applications that depend on message
ARC0036I, ARC0503I, or ARC0704I and applications triggered by message
type.<a id="idx980"></a><a id="idx981"></a><a id="idx982"></a><a id="idx983"></a><a id="idx984"></a><a id="idx985"></a><a id="idx986"></a><a id="idx987"></a><a id="idx988"></a></p>
<table id="wq530" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMShsm.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your applications depend on message
ARC0036I, ARC0503I, or ARC0704I or if your applications are triggered
by message type.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Update applications that: 
</p>
<ul>
<li>depend on ARC0036I to work with ARC0036E.</li>
<li>depend on ARC0503I to work with ARC0503E.</li>
<li>depend on ARC0704I to work with ARC0704E.</li>
<li>are triggered by message type.</li></ul>
<p><strong>Reference information</strong>: For more information about DFSMShsm
messages, see <cite>z/OS MVS System Messages, Vol 2 (ARC-ASA)</cite>.</p>
<h4 id="ptchmcvt">DFSMShsm: Remove patch that prevents SMS MVT chain rebuild</h4>
<p>[[[[ Contributing writer: Martha A Burns/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Sean P McMillen/Tucson/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13, the flag at MCVT+C8 X'80'
was used to prevent the SMS MVT chain rebuild at the beginning of
primary space management and at the beginning of interval migration,
based on the current SMS storage group definitions. If the SMS storage
groups had not been changed and no new SMS volumes had been added
since the last time primary space management or interval migration
was run, you could prevent the SMS MVT chain from being needlessly
rebuilt or refreshed by entering the following PATCH command:</p>
<p><span class="synph"><span class="kwd">PATCH .MCVT.+C8 BITS(1.......)</span></span></p>
<p>Starting with z/OS V1R13, this flag is maintained automatically
by DFSMShsm. DFSMShsm checks for the occurrence of an ENF 15 event
at the beginning of primary space management, at the beginning of
interval migration, and at the beginning of on-demand migration. When
an ENF 15 event is reported, DFSMShsm performs an SMS MVT chain rebuild
or refresh. After a successful SMS MVT chain rebuild, DFSMShsm does
not rebuild or refresh the MVT chain until the next SMS configuration
change (that is, the next ENF 15 event).</p>
<p>Starting with z/OS V1R13, DFSMShsm does not take into account the <span class="synph"><span class="kwd">PATCH
.MCVT.+C8 BITS(1.......)</span></span> command. Nevertheless,  it
is recommended to remove this patch command from the ARCCMD<span class="synph"><span class="var">xx</span></span> parmlib
member of SYS1.PARMLIB to avoid any misunderstanding.<a id="idx989"></a><a id="idx990"></a><a id="idx991"></a><a id="idx992"></a><a id="idx993"></a><a id="idx994"></a><a id="idx995"></a><a id="idx996"></a></p>
<table id="wq531" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMS.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because starting from z/OS
V1R13, the patch command no longer performs a useful function other
than what is already handled automatically by DFSMShsm. Additionally,
it been discovered in the past that leaving unnecessary useless patches
in DFSMShsm's startup procedures can cause confusion and potential
problems.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>Remove this patch when all systems are at z/OS
V2R1 if a common DFSMShsm's startup procedure is shared with downlevel
systems.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Remove <span class="synph"><span class="kwd">PATCH .MCVT.+C8 BITS(1.......)</span></span> from
the ARCCMD<span class="synph"><span class="var">xx</span></span> parmlib member of SYS1.PARMLIB.</p>
<p><strong>Reference information</strong>: None.</p>
<h4 id="hsmarccat">DFSMShsm: Stop using the HOLD command to quiesce activity prior
to control data set backup</h4>
<p>[[[[ Contributing writer: Michael Forte/Poughkeepsie/IBM
]]]] [[[[ Technical contacts: Snehal S Bhakta/Tucson/IBM, Glenn Wilcock/Tucson/IBM]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13,
you might have manually or programmatically held DFSMShsm activity
using the <strong>HOLD</strong> command prior to starting a control data set
(CDS) backup. Starting with z/OS V1R13,
the ARCCAT resource is released by all functions running on z/OS V1R13 DFSMShsm hosts, and
the functions are quiesced when CDS backup starts. Manually or programmatically
holding DFSMShsm activity is no longer necessary.<a id="idx997"></a><a id="idx998"></a></p>
<table id="wq532" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMShsm.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because DFSMShsm will automatically
release the ARCCAT resource when a CDS backup is starts.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>Cross coupling facility (XCF) services are required
to communicate the start of a CDS backup to all DFSMShsm hosts. XCF
services must be available and configured properly.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>The following are restrictions of taking this
migration action. 

<ul>
<li>In a record-level sharing (RLS) CDS environment, all DFSMShsm
hosts in the HSMPlex must be z/OS V1R13 or later hosts.</li>
<li>In a non-RLS CDS environment, this migration action can be taken
on z/OS V1R13 DFSMShsm hosts without changing hosts running on prior
releases of z/OS.</li>
<li>Some DFSMShsm environment configuration do not require XCF services.
Specifically, a non-RLS CDS non-multiple address space DFSMShsm (MASH)
configuration typically does not require XCF services. However, XCF
services are required and must be available and configured in all
DFSMShsm RLS CDS and MASH configurations.</li></ul></td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>If you continue to issue a HOLD command to quiesce
DFSMShsm activity before a CDS backup and a corresponding RELEASE
command to resume activity after CDS backup is complete, the only
impact is that you will not see the performance benefit intended by
this enhancement.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: On all z/OS V1R13
DFSMShsm hosts:</p>
<ol type="1">
<li>Remove the procedures, processes, or programs that issue the <strong>HOLD</strong> command
to quiesce DFSMShsm activity prior to starting CDS backup.</li>
<li>Remove the corresponding procedures, processes, or programs that
issue the <strong>RELEASE</strong> command to resume DFSMShsm activity after
CDS backup completes.</li></ol>
<p><strong>Reference information</strong>: For an overview of the CDS backup
enhancement that relieves ARCCAT resource contention, see <cite>z/OS DFSMS Using the New Functions</cite>ll .</p>
<h4 id="dt2mg678">DFSMSrmm: Check how you control your RACF tape profile processing</h4><a id="idx999"></a>
<p></p>
<p><strong>Description</strong>: Since z/OS V1R8 DFSMSrmm supports the TAPEAUTHDSN
parameter in the DEVSUPxx (device support) parmlib member; however,
this support has required enhancements in z/OS V2R1 to be properly
implemented.</p>
<p> Before z/OS V2R1, TAPEAUTHDSN=YES RMM performed tape authorization
checks in the DATASET class against discrete profiles through RACF.</p>
<p>TAPEAUTHDSN=YES DFSMSrmm performed tape authorization checks  in
the DATASET class with DSTYPE=T to indicate to RACF that the check
was for data sets on tape volumes and that a RACF check for authority
to a discrete data set profile had been performed.  With z/OS V2R1
DFSMSrmm correctly supports option TAPEAUTHDSN according to the documentation
in <cite>zOS MVS Initialization and Tuning Guide</cite> and in <cite>z/OS
DFSMSrmm Implementation and Customization Guide</cite>.  If TAPEAUTHDSN=YES
is set, DFSMSrmm now performs authorization checking without DSTYPE=T.
The RACROUTE is issued in the DATASET class as if for a DASD data
set.</p>
<p>You had a working setup ("TAPEAUTHDSN=YES with discrete profiles"
or "TAPEAUTHDSN=NO with generic profiles" If you want to continue
with existing setting "TAPEAUTHDSN=YES". then you need to create generic
profiles now. If you want to continue with existing generic profiles,
you need to set "TAPEAUTHDSN=NO" now.</p>
<table id="wq534" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMSrmm</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes,
if you have set up the RACF implementation.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Check
to determine if you use the TAPEAUTHDSN=YES option in your DEVSUPxx
parmlib member. If the option is implemented, based on your overall
RACF and DFSMSrmm configuration that you use with discrete data set
profiles, you must prepare for a change in processing after you IPL
V2R1:
</p>
<ol type="1">
<li>If you want to continue using your existing data set profiles
(generic or discrete), you need the exchange the current TAPEAUTHDSN
settings.  TAPEAUTHDSN=YES will now make use of generic profiles;
TAPEAUTHDSN=NO will now make us of discrete profiles."</li></ol>
<p>.</p>
<p><strong>Reference information:</strong> See
 "Recommendations for using RACF tape profile processing" in <em>z/OS
DFSMSrmm Implementation and Customization Guide</em>.  See "Enhanced
security for tape data sets" in <em>zOS MVS Initialization and Tuning
Guid</em>e.</p>
<h3 id="e0z3m100-gen110">DFSMS actions
to perform after the first IPL of z/OS V2R1</h3>
<p>This topic describes DFSMS migration actions that you can perform
only after you have IPLed z/OS V2R1.
You need a running z/OS V2R1
system to perform these actions.</p>
<p><a href="e0z3m100.htm#bindgra">DFSMSdfp:
Run OAM DB2 BIND jobs</a></p>
<p><a href="e0z3m100.htm#dfpsms1">DFSMSdfp: Configure clusters and storage groups for SMS volume
selection</a></p>
<p><a href="e0z3m100.htm#oamconf">DFSMSdfp: Run OAM configuration database migration job</a></p>
<p><a href="e0z3m100.htm#armode64">DFSMSdfp: Accommodate 64-bit and AR mode rules enforcement
in DFSMS macros</a></p>
<p><a href="e0z3m100.htm#voltrack1">DFSMSdss: Accommodate new default behavior for full-volume
and track restore operations</a></p>
<p><a href="e0z3m100.htm#copyvolid">DFSMSdss: Review changes to the messages that result from a
COPY or RESTORE operation with COPYVOLID</a></p>
<p><a href="e0z3m100.htm#dfshsmds">DFSMShsm: Prepare to handle DFSMShsm changes to the key of
some of its CDS records, backup data set name format, and migrated
data sets</a></p>
<h4 id="dt2mg682">DFSMSdfp:
Run OAM DB2 BIND jobs</h4>
<p>[[[[ Contributing writer: James E Becker/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Sherrie Niederbrach/Tucson/IBM@IBMUS
]]]] [[[[ Technical contact: Brian Corkill/Tucson/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: When migrating to any new release of z/OS,
you must run OAM DB2 BIND jobs
if you are using OAM for object support. The BIND jobs update DB2 with new OAM DB2 code.</p>
<table id="wq536" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx1000"></a><a id="idx1001"></a><a id="idx1002"></a><strong>Element
or feature</strong>:</td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use OAM object support.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Run the BIND jobs appropriate to your installation:</p>
<ol type="1">
<li>Update and execute the samplib job CBRPBIND (OAM DB2 Bind Package Job).</li>
<li>Do one of the following: 

<ul>
<li>If your installation starts OAM, uses the file system sublevel
or optical or tape devices, or uses the OAM storage management component
(OSMC), do the following: 

<ul>
<li>Update and execute samplib job CBRABIND (OAM DB2 Application Plan Bind for LCS and OSR).</li>
<li>Update and execute samplib job CBRHBIND (OAM DB2 Application Plan Bind for OSMC).</li></ul></li>
<li>If your installation does not start OAM, use the file system sublevel
or optical or tape devices, or use OSMC, update and execute samplib
job CBRIBIND (OAM DB2 Application Plan Bind for OSR only).</li></ul></li>
<li>For more information, see the topic "Migrating, Installing, and
Customizing OAM" in <cite>z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Object Support</cite>.</li></ol>
<p>  </p>
<div>
<div class="note-noindent" id="wq538">
<span class="notetitle">Note:</span> <span class="notebody">If you choose to edit a previous version of an OAM BIND
job, you must incorporate any new changes as described in the header
of each samplib OAM BIND job.</span></div></div>
<p><strong>Reference information</strong>: For more information about OAM, see <cite>z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Object Support</cite>.</p>
<h4 id="dfpsms1">DFSMSdfp: Configure clusters and storage groups for SMS volume
selection</h4>
<p>[[[[ Contributing writer: Bill Keller]]]]
[[[[ Technical contact: Victor Liang]]]]</p>
<p><strong>Description</strong>: Before z/OS V2R1, when allocating or extending
a multi-volume data set, SMS preferred the candidate volumes in the
same storage facility image (SFI) if the storage class accessibility
attribute was set to CONTINUOUS or CONTINUOUS PREFERRED. With z/OS
V2R1, SMS prefers volumes that are in the same cluster. Similarly,
when allocating the target data set for the data set fast replication
function, SMS now prefers volumes that are in the same cluster as
the source data set. In both cases, if it is not possible to honor
the preference of volumes in the cluster, SMS reverts to preferring
volumes in the same SFI. If you wish SMS to select volumes in the
same cluster, you should configure your clusters accordingly.<a id="idx1003"></a></p>
<p>Before z/OS V2R1, when allocating a striped data set, SMS allocated
the stripes across separate logical control units (LCUs). With z/OS
V2R1, SMS attempts to allocate the stripes across separate extent
pools. If this is not possible, SMS continues to allocate the stripes
across LCUs. If you wish SMS to separate the stripes across extent
pools, you should configure your storage groups accordingly.</p>
<table id="wq539" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended for optimum efficiency of
data set fast replication and for the most uniform performance with
striped data sets.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If you wish SMS to select volumes in the
same cluster, configure your clusters accordingly.</p>
<p>For striped data sets, if you wish SMS to separate the stripes
across extent pools, configure your storage groups accordingly.</p>
<p><strong>Reference information</strong>: For details about SMS volume selection
and about striped data sets, refer to<cite>z/OS DFSMSdfp Storage Administration</cite>.</p>
<h4 id="oamconf">DFSMSdfp: Run OAM configuration database migration job</h4>
<p>[[[[ Contributing writer: David J Cornell/Poughkeepsie/IBM@IBMUS]]]]
[[[[ Technical contact: Kevin Goldsmith/Tucson/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: When migrating to z/OS V1R13, you must run
the OAM configuration database migration job (CBRSMR1D). CBRSMR1D
creates the File System Delete Table in the OAM Configuration Database.
If you use OAM object support, you must run CBRSMR1D even if you do
not plan to use OAM file system support. <a id="idx1004"></a><a id="idx1005"></a></p>
<table id="wq540" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use OAM object support.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>If you use OAM object support, you must run CBRSMR1D even if you
do not plan to use OAM file system support. Update and run the OAM
configuration database migration job (CBRSMR1D) provided in SAMPLIB.</li>
<li>Run OAM DB2 BIND and GRANT jobs. To determine which BIND and GRANT
jobs you need to run, see <cite>z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Object Support</cite>.</li></ol>
<p><strong>Reference information</strong>: For more information, see the topic
"Migrating, Installing, and Customizing OAM" in  <cite>z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Object Support</cite>.</p>
<h4 id="armode64">DFSMSdfp: Accommodate 64-bit and AR mode rules enforcement
in DFSMS macros</h4><a id="idx1006"></a><a id="idx1007"></a><a id="idx1008"></a><a id="idx1009"></a><a id="idx1010"></a><a id="idx1011"></a>
<p>[[[[ Contributing writer: William Keller/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Wayne Rhoten/San Jose/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13, many DFSMS macros that did
not support 64-bit or AR mode did not react to being invoked in 64-bit
or AR mode, and generated code that might have been invalid in 64-bit
or AR mode. Starting with z/OS V1R13, these macros are changed to
issue an assembly-time message and suppress expansion if they are
invoked in 64-bit or AR mode. If you have code, including exits, that
invokes DFSMS macros, you should review your code and modify it as
appropriate to accommodate the new enforcement of 64-bit and AR mode
rules.<a id="idx1012"></a><a id="idx1013"></a></p>
<table id="wq542" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMSdfp.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have code, including exits, that
invokes DFSMS macros.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Modify your source code so that no DFSMS
macros are invoked after the SYSSTATE macro specifies 64-bit or AR
mode. (The one exception is the TRKADDR macro, which supports 64-bit
mode.) When you assemble your code, if a return code of 8 or greater
is returned by the High Level Assembler, check for assembler messages
that indicate that a macro has been invoked after AMODE 64 or AR mode
was specified on the SYSSTATE macro.</p>
<p>Change the source code as appropriate: 
</p>
<ul>
<li>If the macro invocation will be executing in a supported environment
(31-bit or 24-bit and not AR mode), then precede that invocation with
SYSSTATE AMODE64=NO,ASCENV=P.</li>
<li>If your tests show that the macro expansion does work when invoked
in 64-bit or AR mode, then you can consider coding SYSSTATE with AMODE64=NO
and ASCENV=P even though it does not match the execution environment.
 This type of macro invocation is not supported by IBM unless the
documentation for that macro says otherwise.</li></ul>
<p><strong>Reference information</strong>: For details about DFSMS macros, refer
to <cite>z/OS DFSMS Macro Instructions for Data Sets</cite> and <cite>z/OS DFSMSdfp Advanced Services</cite>.</p>
<h4 id="voltrack1">DFSMSdss: Accommodate new default behavior for full-volume
and track restore operations</h4>
<p>[[[[ Contributing writer: Bill Keller]]]]
[[[[ Technical contact: Jason R. Luurs]]]]</p>
<p><strong>Description</strong>: The data-set-changed indicator (DS1DSCHA) in
the VTOC indicates whether or not the data set has changed since its
last backup.  Before z/OS V2R1, during a full-volume restore operation,
DFSMSdss unconditionally reset (turned off) the data-set-changed indicator
for each data set restored to the target volume. During a tracks restore
operation, if any VTOC track was restored, DFSMSdss might reset the
data-set-changed indicator for all data sets on the volume. <span>This
applies to all VSAM and non-VSAM data sets and all SMS and non-SMS
data sets. </span><a id="idx1014"></a><a id="idx1015"></a></p>
<p>With z/OS V2R1, the default behavior for full-volume and tracks
restore operations has changed. By default, DFSMSdss now resets the
data-set-changed indicator only if the RESET keyword was specified
on the DUMP command. Along with this change, a RESET keyword has been
added to the RESTORE FULL and RESTORE TRACKS commands, which allows
you to specify whether the data-set-changed indicator is to be reset.
In addition, you can use the options installation exit routine, ADRUIXIT,
to control the resetting of the data-set-changed indicator.</p>
<p>You can use RESET on the RESTORE command for any FULL
or TRACKS dump taken with V2R1, or any previous releases. RESET(YES)
and RESET(NO) will work as expected. However, RESET(DUMP) will act
as RESET(NO) because there is no way to determine if the RESET keyword
was specified at DUMP time on a down-level dump. The new RESET(DUMP)
functionality is only available in V2R1.</p>
<p>Note that the default behavior for DFSMSdss DUMP is unchanged
when DFSMShsm invokes DFSMSdss to perform a full volume restore. By
default, DFSMShsm will pass RESET(YES) to DFSMSdss. The other parameters
might be specified through the DEFINE DUMPCLASS command.</p>
<table id="wq543" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSMSdss.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want DFSMSdss to unconditionally
reset the data-set-changed indicator during full-volume and tracks
restore operations.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>The new default behavior is not in effect with
dumps taken before z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: To obtain the behavior in previous releases
to allow DFSMSdss to unconditionally reset the data-set-changed indicator
during full-volume and tracks restore operations, use RESET(YES) with
the RESTORE FULL and RESTORE TRACKS commands. The other options for
the RESET keyword are:  
</p>
<dl class="parml">
<dt class="bold">NO</dt>
<dd>DFSMSdss does not alter the DS1DSCHA values. Each DS1DSCHA represents
the value the data sets had at the time the dump was taken.
</dd>
<dt class="bold">DUMP</dt>
<dd>DFSMSdss resets the data-set-changed indicator (DS1DSCHA=OFF)
only if the RESET keyword was specified on the DUMP command.  This
is the default.
</dd>
</dl>
<p>You can also use the options installation exit routine ADRUIXIT
or API programs to override the behavior. The ADRUFO parameter list
contains these bits in the UFO8FLGS structure: 
</p>
<dl class="parml">
<dt class="bold">UFO8RESY</dt>
<dd>Corresponds to RESET(YES)
</dd>
<dt class="bold">UFO8RESN</dt>
<dd>Corresponds to RESET(NO)
</dd>
<dt class="bold">UFO8RESD</dt>
<dd>Corresponds to RESET(DUMP).
</dd>
</dl>
<div>
<div class="note-noindent" id="wq544">
<span class="notetitle">Note:</span> <span class="notebody"> 

<ul>
<li>The default behavior is unchanged when DFSMShsm invokes DFSMSdss
to perform a full volume restore. By default, DFSMShsm will pass RESET(YES)
to DFSMSdss. You can specify the other parameters through the DEFINE
DUMPCLASS command.</li>
<li>DFSMSdss has been changed to allow the DS1DSCHA bit to
remain on even after a full or partial RESTORE when PATCH byte <samp>x'52'</samp> is
set to a non-zero value. If an API is used to invoke DFSMSdss, the
PATCH will not be honored and the DS1DSCHA bit will be reset as normal.
You can discontinue this approach once migrating to z/OS V2R1 DFSMSdss
by using this new functionality.</li></ul></span></div></div>
<p><strong>Reference information</strong>: For details about the RESTORE command,
see <cite>z/OS DFSMSdss Storage Administration</cite>.
For details about the installation exit, see <cite>z/OS DFSMS Installation Exits</cite>.</p>
<h4 id="copyvolid">DFSMSdss: Review changes to the messages that result from a
COPY or RESTORE operation with COPYVOLID</h4><a id="idx1016"></a><a id="idx1017"></a>
<p>[[[[ Contributing writer: Sonja Moore/Durham/Contr/IBM@IBMUS
]]]] [[[[ Original technical contact: Greg Callis/Raleigh/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: With APAR OA36296, DFSMSdss uses the
IEEVARYD service, rather than the VARY command, to vary the target
volume offline during a COPY or RESTORE operation with either FULL
or TRACKS and the COPYVOLID parameter, when the target volume becomes
a duplicate of the source volume. As a result, the hardcopy log no
longer contains: 
</p>
<ul>
<li>VARY device-number,OFFLINE DFSMSDSS INTERNAL VARY</li>
<li>IEF281I device-number NOW OFFLINE.</li></ul><p class="indatacontent">Instead, the hardcopy log contains message IEF880I, as follows: </p>
<pre class="xmp"><code>IEF880I device-number NOW OFFLINE BY ADRSBRTN</code></pre>
<p>Programs or procedures that rely on the presence of either the
VARY command or the IEF281I message in the hardcopy log or job logs
should be updated.</p>
<table id="wq545" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td></td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td align="left">Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the PTF for APAR OA36296 has been applied
and you have programs or procedures that rely on the presence of either
the VARY command or the IEF281I message.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Modify your programs or procedures to check
for the new message:     </p>
<pre class="xmp"><code>IEF880I device-number NOW OFFLINE BY ADRSBRTN</code></pre><p class="indatacontent">This
message indicates that the device has been varied offline as the result
of a DFSMSdss operation with the COPYVOLID parameter.</p>
<p><strong>Reference information:</strong> For more information about COPY and
RESTORE, see <cite>z/OS DFSMSdfp Storage Administration</cite></p>
<h4 id="dt2mg683">DFSMShsm: Prepare to handle DFSMShsm changes to the key of
some of its CDS records, backup data set name format, and migrated
data sets</h4><a id="idx1018"></a>
<p>[[[[ Contributing writer: Sonja Moore/Durham/Contr/IBM@IBMUS
]]]] [[[[ Original technical contact: Greg Callis/Raleigh/IBM@IBMUS
]]]]TBD</p>
<p><strong>Description</strong>: As of z/OS V2R1 DFSMShsm is changing the key
of some of its CDS records, the backup data set name format and migrated
data sets.</p>
<p>When HSM creates its CDS records and the backup or migration target
dataset name (HSMDSN), it generates the name using the first two qualifiers
of the source DS along with the time and date. The cds records affected
are the MCC, MCM, MCA, and MCO.</p>
<p>As of z/OS V2R1 the HSM data set name format is: </p>
<pre class="xmp"><code>prefix.func.Tcccchh.user1.user2.Xyddd</code></pre><p class="indatacontent"> The
3rd qualifier is now <samp class="xph">Tcccchh</samp>, where '<samp class="xph">cccc</samp>'
is hundredths of seconds from the beginning of the hour converted
to four alphabetic characters.</p>
<table id="wq546" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>DFSMShsm</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1. APAR OA38729????????</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td align="left">After first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if DFSMShsm data set creation
collision (<samp class="xph">hsmdsn</samp> ) occurs frequently as this change
can help reduce some processing time.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>ZOSMIGV2R1_CS_GATEWAY can help you determine
if you are using any GATEWAY statements in your TCP/IP profile.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: For any program/tool that inspects the HSMDSN
time qualifier, use the pseudo code provided in <cite>z/OS DFSMSdfp Storage Administration</cite> to
decode the time portion of the HSMDSN.</p>
<p><strong>Reference information:</strong> <cite>z/OS DFSMSdfp Storage Administration</cite>.</p>
<h2 id="dfsomig1">DFSORT migration
actions</h2>
<p>This topic describes migration actions for optional feature DFSORT.</p>
<h3 id="e0z3m100-gen111">DFSORT actions
to perform before installing z/OS V2R1</h3><a id="idx1019"></a>
<p>This topic describes DFSORT migration actions that you can perform
on your current (old) system. You do not need the z/OS V2R1 level
of code to make these changes, and the changes do not require the
z/OS V2R1 level of code to run once they are made.</p>
<p>None.</p>
<h3 id="dt2mg686">DFSORT actions
to perform before the first IPL of z/OS V2R1</h3>
<p>This topic describes DFSORT migration actions that you can perform
after you have installed z/OS V2R1 but before the first time you IPL.
These actions might require the z/OS V2R1
level of code to be installed but do not require it to be active.</p>
<p><a href="e0z3m100.htm#dfsomsg1">Update automation for changed DFSORT messages</a></p>
<p><a href="e0z3m100.htm#tunedfsort1">Use TUNE=OLD option to prevent balancing resources for concurrent
sort applications</a></p>
<p><a href="e0z3m100.htm#expold1">Use EXPOLD=MAX and EXPRES=0 to prevent changed defaults</a></p>
<h4 id="dt2mg687">Update automation for changed DFSORT messages</h4><a id="idx1020"></a><a id="idx1021"></a><a id="idx1022"></a><a id="idx1023"></a><a id="idx1024"></a><a id="idx1025"></a>
<p>[[[[ Contributing writer: James E Becker/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Vicky Vezinaw/San Jose/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: In z/OS V2R1,
the text for some DFSORT messages
(ICE<span class="synph"><span class="var">xxxx</span></span>) is changed. Text and insert fields
have been added, changed, or removed in the messages listed below
in &quot;Steps to take&quot;. These changes can affect automation programs
that examine the text of the messages.</p>
<table id="wq547" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSORT.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have automation routines that examine
the message text of the messages listed below in &quot;Steps to take&quot;.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Update your automation to handle the following DFSORT message
changes: 
</p>
<ul>
<li></li>
<li>The product number has changed from &quot;5694-A01&quot; to &quot;5650-ZOS&quot;,
and the release level has changed from "V1R12" to "V2R1 ", in message
ICE000I.</li>
<li>The following new messages have been added:   

<ul>
<li>ICE290A</li>
<li>ICE291I</li></ul></li>
<li>Text and insert fields have been changed in the following messages
to provide new information:    

<ul>
<li>ICE083A</li>
<li>ICE118I</li>
<li>ICE141A</li>
<li>ICE236I</li>
<li>ICE285A</li>
<li>ICE997I</li></ul></li></ul>
<p><strong>Reference information</strong>: For details about the ICE messages,
see <cite>z/OS DFSORT Messages, Codes and Diagnosis Guide</cite>.</p>
<h4 id="dt2mg688">Use TUNE=OLD option to prevent balancing resources for concurrent
sort applications</h4><a id="idx1026"></a><a id="idx1027"></a><a id="idx1028"></a><a id="idx1029"></a><a id="idx1030"></a><a id="idx1031"></a>
<p>[[[[ Technical contact: Frank Yaeger/San
Jose/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Beginning with z/OS V2R1, a new TUNE installation
default allows you to specify whether DFSORT should allocate storage
in increments with additional disk work space to minimize the risk
of failure, or to allocate all storage at initialization so disk work
space allocation can be reduced.  The IBM-supplied default for the
new TUNE installation option is TUNE=STOR which specifies allocation
of available central storage as needed in increments sized to balance
resource usage for concurrent sorts.  If you want DFSORT to allocate
available central storage using fixed sized increments, as in previous
releases, you can set TUNE=OLD.</p>
<p>TUNE has the following values:
</p>
<ul>
<li>STOR</li>
<li>DISK</li>
<li>DDYN</li>
<li>OLD</li></ul><a id="idx1032"></a><a id="idx1033"></a><a id="idx1034"></a>
<table id="wq548" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSORT.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the default value TUNE=STOR is not acceptable.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>ICEPRMxx member(s) of PARMLIB can be shared
between systems running different releases of DFSORT. Any installation
options specified in the ICEPRMxx member that are only supported in
the newer release of DFSORT will be ignored on the system using the
lower release of DFSORT.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ul>
<li>Use ICEPRMxx members activated by a START ICEOPT started task
command to set the TUNE=OLD  option, as appropriate.</li>
<li>Alternatively, you can set TUNE=OLD with the previous (less preferred)
method of using the ICEMAC macro and usermods.</li></ul>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li> For details about the TUNE installation option, see <cite>z/OS DFSORT Installation and Customization</cite>.</li></ul>
<h4 id="dt2mg689">Use EXPOLD=MAX and EXPRES=0 to prevent changed defaults</h4>
<p>[[[[ Technical contact: Frank Yaeger/San
Jose/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Beginning with z/OS V2R1, IBM-supplied defaults
have been changed to EXPOLD=50% (from EXPOLD=MAX) and to EXPRES=10%
(from EXPRES=0). If you want DFSORT to use the old defaults, as in
previous releases, you can set EXPOLD=MAX and EXPRES=0.<a id="idx1035"></a><a id="idx1036"></a><a id="idx1037"></a><a id="idx1038"></a></p>
<table id="wq549" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>DFSORT.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if the new defaults are not acceptable.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ul>
<li>Use ICEPRMxx members activated by a START ICEOPT started task
command to set the EXPOLD=MAX or EXPRES=0 options, as appropriate.</li>
<li>Alternatively, you can set EXPOLD=MAX or EXPRES=0 with the previous
(less preferred) method of using the ICEMAC macro and usermods.</li></ul>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li> For details about the EXPOLD and EXPRES installation options,
see <cite>z/OS DFSORT Installation and Customization</cite>.</li></ul>
<h3 id="e0z3m100-gen113">DFSORT actions
to perform after the first IPL of z/OS V2R1</h3>
<p>This topic describes DFSORT migration actions that you can perform
only after you have IPLed z/OS V2R1. You need a running z/OS V2R1
system to perform these actions.</p>
<h2 id="dfsmiga1">Distributed File Service migration actions</h2>
<p>This topic describes migration actions for base element Distributed
File Service.</p>
<h3 id="e0z3m100-gen114">Distributed File Service actions to perform before installing
z/OS V2R1</h3><a id="idx1039"></a>
<p>This topic describes Distributed File Service migration actions
that you can perform on your current (old) system. You do not need
the z/OS V2R1 level of code
to make these changes, and the changes do not require the z/OS V2R1 level of code to run
once they are made.</p>
<p><a href="e0z3m100.htm#remclone1">Remove usage of zFS clone function</a></p>
<p><a href="e0z3m100.htm#newdasd">zFS: Accommodate new DASD space requirements</a></p>
<p><a href="e0z3m100.htm#clonewith">zFS: Copy cloned file systems to a compatibility mode aggregate</a></p>
<p><a href="e0z3m100.htm#msaggreg">zFS: Copy data from zFS multi-file system aggregates to zFS
compatibility mode aggregates</a></p>
<p><a href="e0z3m100.htm#disdfsc">DCE/DFS: Disable DFS Client initialization</a></p>
<p><a href="e0z3m100.htm#filesyszfs">zFS: Ensure sysplex=filesys is available on all zFS R11 and
R12 systems in a shared file system environment</a></p>
<h4 id="remclone1">Remove usage of zFS clone function</h4><a id="idx1040"></a><a id="idx1041"></a><a id="idx1042"></a><a id="idx1043"></a><a id="idx1044"></a><a id="idx1045"></a>
<p>[[[[ Contributing writer: Nancy A Lewallen/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: James Showalter/Endicott/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Beginning with z/OS V2R1, the zFS clone function
is no longer supported. z/OS V1R13 is the last release in which zFS
supports cloning file systems. You must discontinue using zFS clone
functions, such as the zfsadm clone and zfsadm clonesys commands.
You should also discontinue mounting any zFS file system aggregates
that contain a cloned (.bak) file system.<a id="idx1046"></a><a id="idx1047"></a></p>
<table id="wq550" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>z/OS Distributed File Service</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>With <strong>IBM United States Software Announcement
211-007</strong>, dated February 15, 2011.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are using or have used the zFS clone
function.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>If any system earlier than z/OS V2R1 mounts
a zFS aggregate that contains a .bak (clone) file system in a shared
file system environment, any catch-up mounts on a V2R1 system fail
and z/OS UNIX function ships from the V2R1 system to the z/OS UNIX
owning system.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Determine whether you have any .bak file
systems. You can do this by issuing a command like the following: </p>
<pre class="xmp"><code>zfsadm lsfs | grep .bak</code></pre><p class="indatacontent"> You
might see results as in this example: </p>
<pre class="xmp"><code>PLEX.JMS.AGG1.bak (Not Mounted) 458 K alloc 458 K quota On-line 
PLEX.JMS.AGG2.bak (Not Mounted) 26 K alloc 26 K quota On-line</code></pre><p class="indatacontent"> This
example shows that there are two zFS aggregates that contain a .bak
file system - PLEX.JMS.AGG1 and PLEX.JMS.AGG2. In this case, unmount
the .bak file systems (if they are mounted) and delete each .bak file
system from the aggregate with a command similar to the following
example: </p>
<pre class="xmp"><code>zfsadm delete PLEX.JMS.AGG1.bak</code></pre><p class="indatacontent"> (Note
that the file system name is case-sensitive.) If the delete fails
because the file system was not found, it probably means that the
zFS aggregate is not attached. Attach it, delete the .bak file, and
detach the aggregate.</p>
<p>You should delete all .bak file systems before you bring zFS into
the shared file system environment or before you IPL the V2R1 system.
Minimally, you must ensure that no zFS aggregates that contain .bak
file systems are mounted.</p>
<p><strong>Reference information</strong>: For more information, see <cite>z/OS Distributed File Service zFS Administration</cite>.</p>
<h4 id="newdasd">zFS: Accommodate new DASD space requirements</h4><a id="idx1048"></a><a id="idx1049"></a><a id="idx1050"></a><a id="idx1051"></a>
<p>[[[[ Contributing writer: Kathleen Bayconish/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: James Showalter/Endicott/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: zFS always reads and writes data in
8K blocks. However, starting in z/OS V1R13, zFS stores data either
inline or in 8K blocks. (Inline data is a file that is smaller than
53 bytes and is stored in the file's metadata.) Unlike in previous
releases, z/OS V1R13 zFS no longer stores data in 1K fragments. z/OS
V1R13 zFS can read data stored in fragments; however, when the data
is updated, it is moved into 8K blocks. Previously, zFS could store
data in 1K fragments (contained in an 8K block). This meant that multiple
small files could be stored in a single 8K block.<a id="idx1052"></a><a id="idx1053"></a></p>
<p>Because data is no longer stored in fragments, zFS might need more
DASD storage than was required in previous releases to store the same
amount of data. More storage may also be needed if z/OS V1R13 zFS
is in a mixed-release sysplex and becomes the zFS owning system of
a file system.</p>
<p>Because data is no longer stored in fragments, zFS R13 might need
more DASD storage than was required in previous releases to store
the same amount of data. More storage may also be needed if zFS R13
is in a mixed-release sysplex and becomes the zFS owning system of
a file system. 
</p>
<ul>
<li><strong>Scenario 1</strong>: If every file in the file system is 1K or less,
z/OS V1R13 R13 could require up to four times the DASD storage as
was needed in previous releases.</li>
<li><strong>Scenario 2</strong>: Because HFS uses 4K blocks to store data and
zFS uses 8K blocks, if every file in the file system were 4K or less,
z/OS V1R13 zFS could require up to twice as much DASD space to store
these files than HFS did.</li>
<li><strong>Scenario 3</strong>: If the file system contains 1000 files that
are 1K in size, z/OS V1R13 zFS could take a maximum of 10 cylinders
more than zFS in previous releases.</li></ul>
<p>Typically, however, any increase in the DASD storage used by zFS
will be negligible. For example, the z/OS V1R13 version root file
system copied using z/OS V1R13 zFS takes approximately 2% more space
than the same file system copied using z/OS V1R12 zFS. Note that z/OS
V1R13 zFS packs multiple ACLs and symbolic links into an 8K block
which previous releases did not do. To minimize the chance of application
failure due to running out of DASD storage in newly mounted file systems,
the default value for the IOEFSPRM option aggrgrow is changed from <span class="synph"><span class="kwd">Off</span></span> to <span class="synph"><span class="kwd">On</span></span>.</p>
<table id="wq551" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Distributed File Service.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you will be using z/OS V2R1 zFS to create
new zFS file systems or update data in existing file systems, where
the file system contains many small files.  This action is also required
if you have not specified the zFS aggrgrow option in your IOEFSPRM
configuration options file, and want to use the old default of <span class="synph"><span class="kwd">Off</span></span>.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>z/OS V2R1 can use more DASD storage for data
than previous releases required. The amount of DASD storage depends
on file sizes and on ACL and symbolic link usage. In general, the
more small files in the file system, the more likely it is that a
file system created or updated with z/OS V2R1 will require more DASD
storage than previous releases.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Perform the following steps, as appropriate
for your installation.</p>
<p>
<h5 id="wq552">For all zFS file systems</h5></p>
<ol type="1">
<li>If you have not specified the zFS aggrgrow option in
your IOEFSPRM configuration options file, recognize that the default
is changing in z/OS V1R13 from aggrgrow=off to aggrgrow=on. This means
that by default, a zFS read-write mounted file system that is mounted
on z/OS V2R1 will attempt to dynamically extend when it runs out of
space if a secondary allocation size is specified and there is space
on the volume(s).</li>
<li>If you do not want that default change and you want it to act
as in prior releases, specify aggrgrow=off in your IOEFSPRM configuration
options file so that it takes effect on the next IPL. You can dynamically
change the aggrgrow option to off with the <span class="synph"><span class="kwd">zfsadm config
-aggrgrow off</span></span> command. You can see your current value
for aggrgow with the <span class="synph"><span class="kwd">zfsadm configquery -aggrgrow</span></span> command.</li></ol>
<p>
<h5 id="wq554">For new zFS file systems</h5></p>
<ol type="1">
<li>Increase the estimated size of a new zFS file system, if you know
that many files in the file system will be small.</li>
<li>Mount zFS read-write file systems and allow them to dynamically
extend; if more DASD space is needed, applications will not fail because
the file systems are out of storage.  

<p>To do so, mount the file
systems with the AGGRGROW mount option or use the default aggrgrow=on
IOEFSPRM configuration option. The data set must have a non-zero secondary
allocation size and there must be space on the volume to allow dynamic
extension.</p></li></ol>
<p>
<h5 id="wq556">For existing zFS file systems</h5></p>
<ol type="1">
<li>Use the scan for small files utility (zfsspace) to determine if
an existing file system needs more DASD storage. For a mounted zFS
file system, the utility shows the number of small files (1K or less),
if a secondary allocation is specified, and if aggrgrow=on is specified.<span>You can determine how many files you have in a file system
that are less than or equal to 1K in size by using the following shell
command</span>: 
<pre class="xmp"><code><span class="synph"><span class="kwd">find  &lt;mountpoint&gt; -size -3 -type f -xdev | wc -l </span></span></code></pre>  

<p>The
zfsspace utility can be downloaded from <a href="ftp://public.dhe.ibm.com/s390/zos/tools/zfsspace/zfsspace.txt">ftp://public.dhe.ibm.com/s390/zos/tools/zfsspace/zfsspace.txt</a>.<a id="idx1054"></a></p></li>
<li>If a file system has a secondary allocation size and is mounted
with the AGGRGROW mount option, allow it to dynamically extend to
minimize the potential failure due to lack of storage. If there are
insufficient candidate volumes, also consider adding volumes by using
the IDCAMS ALTER command with the ADDVOLUMES option. Generally, after
adding volumes, a remount samemode is required to have them take effect.</li>
<li>If a file system is not enabled to dynamically extend, consider
explicitly growing the file system using the z/OS UNIX <span class="synph"><span class="kwd">zfsadm
grow</span></span> command. This is especially important if the file
system contains many small files that will be updated.</li>
<li>If you expect a file system to grow larger than 4GB (about 5825
3390 cylinders) and it is not SMS-managed with extended addressability,
you will need to copy it to an SMS-managed zFS data set with a data
class that includes extended addressability. To do so, use the <span class="synph"><span class="kwd">pax</span></span> command.
If a zFS aggregate is to be larger than 4GB, it must be SMS-managed
with a data class that includes extended addressability.</li></ol>
<p><strong>Reference information</strong>: Refer to the following documentation
for more information about the migration steps. 
</p>
<ul>
<li>For information about zFS administration tasks and how zFS stores
files, see <cite>z/OS Distributed File Service zFS Administration, SC23-6887</cite>.</li>
<li>For information about VSAM extended addressability and SMS-managed
data sets, see <cite>z/OS DFSMS Implementing System-Managed Storage, SC23-6849</cite>.</li>
<li>For information about the <span class="synph"><span class="kwd">pax</span></span> command,
see <cite>z/OS UNIX System Services Command Reference, SA23-2280</cite>.</li></ul>
<h4 id="clonewith">zFS: Copy cloned file systems to a compatibility mode aggregate</h4>
<p>[[[[ Contributing writer: Kathleen Bayconish/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: James Showalter/Endicott/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: z/OS V1R13 is planned to be the last release
that zFS will support cloning file systems. In anticipation of this
removal of support, you should discontinue using zFS clone functions,
such as the <strong>zfsadm clone</strong> and <strong>zfsadm clonesys</strong> commands.
You should also discontinue mounting any zFS file system aggregates
that contain a cloned (.bak) file system.<a id="idx1055"></a><a id="idx1056"></a></p>
<p>When support for cloning file systems is withdrawn, only zFS compatibility
mode aggregates will be supported.</p>
<table id="wq558" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Distributed File Service.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13 (previewed in z/OS V1R13 Software
Announcement 211-007, dated 15 February 2011).</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your installation uses cloned file systems.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Determine if cloned file systems (.bak) have been created or are
in the process of being created on your system.  

<ul>
<li>Issue the <strong>modify zfs,query</strong> command and review the contents
of the FILE report. The Flg field in the report will indicate the
status of the file system aggregate.</li></ul></li>
<li>If your system contains cloned file systems, copy that data to
a compatibility mode aggregate.</li></ol>
<p><strong>Reference information</strong>: For more information about zFS commands
and performing administration tasks, see <cite>z/OS Distributed File Service zFS Administration, SC23-6887</cite>.</p>
<h4 id="msaggreg">zFS: Copy data from zFS multi-file system aggregates to zFS
compatibility mode aggregates</h4>
<p>[[[[ Contributing writer: Kathleen Bayconish/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: James Showalter/Endicott/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: z/OS V1R13 was the last release of
zFS support for multi-file system aggregates. If you have data stored
in zFS multi-file system aggregates, you should copy the data from
the zFS multi-file system aggregates into zFS compatibility mode aggregates. <a id="idx1057"></a><a id="idx1058"></a></p>
<p>As of z/OS V2R1, only zFS compatibility mode aggregates are supported,
only zFS compatibility mode aggregates will be supported.</p>
<table id="wq560" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Distributed File Service.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13 (previewed in z/OS V1R13 Software
Announcement 211-007, dated February 15, 2011).</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>Use check ZOSMIGV1R11_ZFS_RM_MULTIFS or check
ZOSMIGREC_ZFS_RM_MULTIFS to help determine if any multi-file system
aggregates are attached on your system.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Use one of the following methods to determine
if you are using zFS multi-file system aggregates: 
</p>
<ul>
<li>Use the IBM Health Checker for z/OS check referenced
above.</li>
<li>Scan your zFS IOEFSPRM configuration options file for define_aggr
statements.</li>
<li>Scan your /etc/rc file for any <strong>zfsadm attach</strong> commands.</li>
<li>Issue the <strong>zfsadm aggrinfo</strong> command to determine if an aggregate
is a multi-file system aggregate; in the command response, COMP indicates
compatibility mode and MULT indicates multi-file system.</li></ul>
<p> If you are using zFS multi-file system aggregates, copy the data
from each of those file systems into its own zFS compatibility mode
aggregate.</p>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li>For more information about zFS commands and administration tasks,
see <cite>z/OS Distributed File Service zFS Administration, SC23-6887</cite>.</li>
<li>For more information about IBM health checks, refer to <cite>IBM Health Checker for z/OS: User's Guide</cite> .</li></ul>
<h4 id="disdfsc">DCE/DFS: Disable DFS Client initialization</h4>
<p>[[[[Contributing writer: Kathleen Bayconish/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Ron Griffiths/Endicott/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: The DFS client (DFSCM) is a physical file system
that is started during z/OS UNIX initialization based on a FILESYSTYPE
statement in the BPXPRMxx parmlib member. Starting with z/OS V1R13,
the DFS client function is removed.<a id="idx1059"></a><a id="idx1060"></a></p>
<table id="wq561" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Distributed File Service.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13 (previewed in z/OS V1R12 Software
Announcement 210-235, dated July 22, 2010).</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>Use ZOSMIGREC_SMB_RPC available by APAR OA30117.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: For parmlib updates, the following
members should be the only IOEx programs listed in the AUTHPGM section
of the IKJTSOxx parmlib member: 
</p>
<ul>
<li>IOEDFSXP</li>
<li>IOEAGSLV</li>
<li>IOEAGFMT</li>
<li>IOEZADM</li></ul><p class="indatacontent">All other IOEx programs need to be removed.</p>
<div>
<div class="note-noindent" id="wq562">
<span class="notetitle">Note:</span> <span class="notebody">The entry for program IOEDFSXP was introduced in SYS1.SAMPLIB(IKJTSO00)
member by APAR OA37218 in z/OS V1R13.</span></div></div>
<p>If your installation uses the DFS client, you must remove the following
statement from the BPXPRM<span class="synph"><span class="var">xx</span></span> parmlib member
to prevent the client from initializing: </p>
<pre class="xmp"><code>FILESYSTYPE TYPE(DFSC)
	ENTRYPOINT(IOECMINI)
	PARM(&rsquo;ENVAR("_EUV_HOME=/opt/dfslocal/home/dfscm") /
	&gt;DD:IOEDFSD 2&gt;&amp;1&rsquo;)
	ASNAME(DFSCM)</code></pre>
<p>If this migration action is not performed before the first IPL
of z/OS V1R13, you will receive the following error message:  </p>
<pre class="xmp"><code>IOEP12402E:
As of z/OS Version 1 Release 13, the DFS client function has been removed.</code></pre><p class="indatacontent"> z/OS
UNIX will successfully initialize, but you will need to follow the
guidance in the message to remove the entry and restart z/OS UNIX.</p>
<p>If you have not already done so, you should use the z/OS
UNIX <strong>pax</strong> command to migrate any data in DCE DFS or Episode
file systems to other file systems. The recommended general procedure
is as follows:</p>
<ol type="1">
<li>Set up a zFS file system to receive the data.</li>
<li>Copy your DCE DFS or Episode file system data to the zFS file
system, using the z/OS UNIX <strong>pax</strong> command.</li>
<li>Set up a z/OS NFS server to allow data access from a remote z/OS
UNIX system.</li></ol>
<p><strong>Reference information</strong>: Refer to the following documentation
for more information about these migration steps. 
</p>
<ul>
<li>For details about message IOEP12402E, see  <cite>z/OS Distributed File Service Messages and Codes, SC23-6885</cite>.</li>
<li>For information about setting up a zFS file system, see  <cite>z/OS Distributed File Service zFS Administration, SC23-6887</cite>.</li>
<li>For information about the <strong>pax</strong> command, see  <cite>z/OS UNIX System Services Command Reference, SA23-2280</cite>.</li>
<li>For information about NFS, see <cite>z/OS Network File System Guide and Reference</cite> .</li>
<li>For information about SMB, see <cite>z/OS Distributed File Service SMB Administration, SC23-6886</cite> .</li></ul>
<h4 id="filesyszfs">zFS: Ensure sysplex=filesys is available on all zFS R11 and
R12 systems in a shared file system environment</h4>
<p>[[[[Contributing writer: Kathleen Bayconish/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: <span>James Showalter/Endicott/IBM@IBMUS</span> ]]]]</p>
<p><strong>Description</strong>: Beginning with z/OS V1R13, zFS only
runs in sysplex=filesys mode. This requires that all sysplex members
in the shared file system environment must run sysplex=filesys, including
any z/OS V1R11 and z/OS V1R12 systems.<a id="idx1061"></a><a id="idx1062"></a><a id="idx1063"></a></p>
<table id="wq564" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Distributed File Service.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have a shared file system environment
with more than one system in that environment.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>Install the PTF for APAR OA32925 on z/OS V1R11. 

<p>If
a problem occurs when zFS is running sysplex=filesys on a z/OS V1R12
system, you can perform the following steps: 
</p>
<ul>
<li>Remove the sysplex specification from each system or specify sysplex=off
on each system (this is equivalent to the default).</li>
<li>Perform a rolling IPL or restart zFS on each system.</li></ul> 

<p>This procedure cannot be done after zFS on the z/OS V1R13
system has joined the sysplex. If you try to start zFS on another
z/OS V1R13 system after you have changed zFS to sysplex=off on the
z/OS V1R12 system, zFS on z/OS V1R13 will not start. This happens
because zFS on z/OS V1R13 requires all other systems be zFS sysplex=filesys.</p> 

<p>Also,
if you try to bring in zFS z/OS V1R13 when sysplex=filesys is not
active on all systems, you will receive message <samp class="xph">IOEZ00721I
Sysplex member <em>sysname</em> is not running sysplex=filesys.
zFS on this initializing member will terminate.</samp>, where <em>sysname</em> is
the sysplex member that is not running sysplex=filesys.</p></td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>Specifying zFS sysplex=filesys in a shared file
system environment causes zFS to run sysplex-aware on a file system
basis. This is the preferred mode for zFS in a shared file system
environment.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>Use check ZOSMIGV1R13_ZFS_FILESYS<span>(available
with APAR OA35465 on z/OS V1R12)</span>.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Perform the following steps to ensure that
sysplex=filesys is available on all zFS z/OS V1R12 systems in a shared
file system environment.</p>
<ol type="1">
<li>If you are currently running zFS sysplex=off, specify sysplex=filesys
and make it active on all systems through a rolling IPL.  

<p>If you
are running sysplex=on, specify sysplex=filesys and sysplex_filesys_sharemode=rwshare
and make it active on all systems through a rolling IPL. <span>The
health check ZOSMIGV1R13_ZFS_FILESYS verifies that all z/OS V1R12
systems in the shared file system environment have specified sysplex=filesys
before z/OS V1R13 is introduced.</span></p></li></ol>
<p>To determine if you are running zFS sysplex=filesys, issue the
MODIFY ZFS,QUERY,LEVEL operator command. In a shared file system environment,
the last line of the response indicates if zFS is running sysplex=filesys.
In the following example, zFS is running sysplex=filesys.   </p>
<pre class="xmp"><code>f zfs,query,level
IOEZ00639I zFS kernel: z/OS zSeries File System
Version 01.11.00 Service Level OA33895 - HZFS3B0.
Created on Mon Aug 23 14:02:18 EDT 2010.
sysplex(<strong>filesys</strong>,norwshare) interface(3)
IOEZ00025I zFS kernel: MODIFY command - QUERY,LEVEL completed successfully</code></pre>
<p>If you do not perform these steps on z/OS V1R12 systems, you will
receive error messages when you try to bring up zFS on a z/OS V1R13
system. In the examples shown in <a href="e0z3m100.htm#filesyszfs__zfsemsg">Table 14</a>,
DCEIMGVM, DCEIMGVN and DCEIMGVQ are three sysplex members in a shared
file system environment.</p>
<table id="filesyszfs__zfsemsg" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<caption><a href="e0z3m100.htm#FT_Table_14">Table 14. Examples of zFS error messages</a></caption>
<tbody valign="top">
<tr>
<td width="11%"><strong>Example 1</strong></td>
<td width="88%">DCEIMGVM (running z/OS V1R13) tries to enter
the sysplex environment.  

<p>DCEIMGVN and DCEIMGVQ are running z/OS
V1R11 but the coexistance APAR has not been installed on either system.</p></td>
</tr>
<tr>
<td>Results</td>
<td>DCEIMGVM (z/OS V1R13) issues: 
<pre class="xmp"><code>IOEZ00675E zFS will terminate... system DCEIMGVN does not support the following
           feature(s) used by this system (DCEIMGVM):
           enhanced connect
IOEZ00675E zFS will terminate... system DCEIMGVQ does not support the following
           feature(s) used by this system (DCEIMGVM):
           enhanced connect
IOEZ00057I zFS kernel program IOEFSKN is ending</code></pre></td>
</tr>
<tr>
<td><strong>Example 2</strong></td>
<td>DCEIMGVN (running z/OS V1R11 without coexistence
APAR) tries to enter the sysplex environment. 

<p>DCEIMGVM and DCEIMGVQ
are running z/OS V1R13.</p></td>
</tr>
<tr>
<td>Results</td>
<td>DCEIMGVN (z/OS V1R11) issues the following messages: 
<pre class="xmp"><code>IOEZ00677E zFS will terminate... system DCEIMGVM uses feature(s) not supported
           by the initializing system (DCEIMGVN).
IOEZ00677E zFS will terminate... system DCEIMGVQ uses feature(s) not supported
           by the initializing system (DCEIMGVN).
IOEZ00057I zFS kernel program IOEFSCM is ending</code></pre>  

<p>DCEIMGVM
(z/OS V1R13) issues: </p>
<pre class="xmp"><code>IOEZ00676E DCEIMGVN will terminate... it does not support the following
           feature(s) used by this system(DCEIMGVM):
           enhanced connect</code></pre> 

<p>DCEIMGVQ (z/OS V1R13)
issues: </p>
<pre class="xmp"><code>IOEZ00676E DCEIMGVN will terminate... it does not support the following
           feature(s) used by this system(DCEIMGVQ):
           enhanced connect</code></pre></td>
</tr>
<tr>
<td><strong>Example 3</strong></td>
<td>DCEIMGVM (running z/OS V1R13) tries to enter
the sysplex environment. 

<p>DCEIMGVN and DCEIMGVQ (running
z/OS V1R11 with the coexistance APAR installed) are not running sysplex=filesys.</p></td>
</tr>
<tr>
<td>Results</td>
<td>DCEIMGVM (z/OS V1R13) issues:  
<pre class="xmp"><code>IOEZ00721I Sysplex member DCEIMGVN is not running sysplex=filesys.
           zFS on this initializing member will terminate.
IOEZ00721I Sysplex member DCEIMGVQ is not running sysplex=filesys.
           zFS on this initializing member will terminate.
IOEZ00057I zFS kernel program IOEFSKN is ending.</code></pre></td>
</tr>
<tr>
<td><strong>Example 4</strong></td>
<td>DCEIMGVN (running z/OS V1R11 without sysplex=filesys
and with the coexistence APAR installed) tries to enter the sysplex
environment.  

<p>DCEIMGVM and DCEIMGVQ are running z/OS V1R13.</p></td>
</tr>
<tr>
<td>Results</td>
<td>DCEIMGVN (z/OS V1R11 without sysplex=filesys)
issues:   
<pre class="xmp"><code>IOEZ00677E zFS will terminate... system DCEIMGVM uses feature(s)
           not supported by the initializing system (DCEIMGVN).
IOEZ00677E zFS will terminate... system DCEIMGVQ uses feature(s)
           not supported by the initializing system (DCEIMGVN).
IOEZ00057I zFS kernel program IOEFSCM is ending</code></pre> DCEIMGVM
(z/OS V1R13) issues: 
<pre class="xmp"><code>IOEZ00720I Initializing system DCEIMGVN will not be allowed
           to join the sysplex.
           It is not running sysplex=filesys.</code></pre> DCEIMGVQ
(z/OS V1R13) issues:   
<pre class="xmp"><code>IOEZ00720I Initializing system DCEIMGVN will not be allowed
           to join the sysplex.
           It is not running sysplex=filesys.</code></pre></td>
</tr>
</tbody>
</table>
<p><strong>Reference information</strong>: Refer to the following documentation
for more information about these migration steps. 
</p>
<ul>
<li>For details about messages, see <cite>z/OS Distributed File Service Messages and Codes, SC23-6885</cite>.</li>
<li>For more information about running zFS in a shared file system
environment, see <cite>z/OS Distributed File Service zFS Administration, SC23-6887</cite>.</li>
<li>For more information about IBM health checks, refer to <cite>IBM Health Checker for z/OS: User's Guide</cite> .</li></ul>
<h3 id="e0z3m100-gen115">Distributed File Service actions to perform before the first
IPL of z/OS V2R1</h3>
<p>This topic describes Distributed File Service migration actions
that you can perform after you have installed z/OS V2R1 but before the first time you IPL.
These actions might require the z/OS V2R1
level of code to be installed but do not require it to be active.</p>
<p><a href="e0z3m100.htm#dt2mg398">Ensure that the zFS kernel is active when using the batch utility
ioeagfmt</a></p>
<h4 id="dt2mg698">Ensure that the zFS kernel is active when using the batch utility
ioeagfmt</h4><a id="idx1064"></a>
<p></p>
<p><strong>Description</strong>: Before z/OS V2R1, the batch utility<strong><samp>ioeagfmt</samp></strong> did
not require that the zFS kernel be active. Starting in V2R1, <strong><samp>ioeagfmt</samp></strong> requires
that the zFS kernel be active.</p>
<table id="wq566" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>zFS</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you did not run <strong><samp>ioeagfmt</samp></strong> after
the kernel was initialized. However, it would be unusual not to have
zFS active when running <strong><samp>ioeagfmt</samp></strong>.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Look for vendor applications that might be
creating or submitting JCL containing <strong><samp>ioeagfmt</samp></strong> calls
that are run when the zFS kernel is not active. Run them when the
zFS kernel is active. If you are formatting file systems to be used
by another system, you should be setting the  <samp>-version</samp> parameter
on <strong><samp>ioeagfmt</samp></strong> because the local zFS kernel would
not have the information for a remote zFS system. You can also use
the <strong><samp>ioefsutl</samp></strong> program to achieve the same results.</p>
<p><strong>Reference information:</strong></p>
<h3 id="e0z3m100-gen116">Distributed File Service actions to perform after the first
IPL of z/OS V2R1</h3>
<p>This topic describes Distributed File Service migration actions
that you can perform only after you have IPLed z/OS V2R1. You need a running z/OS V2R1 system to perform these actions.</p>
<p><a id="idx1065"></a><a id="idx1066"></a><a id="idx1067"></a><a id="idx1068"></a><a id="idx1069"></a><a id="idx1070"></a>None</p>
<h2 id="dt2mg699">IBM HTTP Server migration actions</h2>
<p>This topic describes migration actions for optional feature IBM
HTTP Server.</p>
<h3 id="dt2mg700">IBM HTTP Server actions to perform before installing z/OS V2R1</h3><a id="idx1071"></a>
<p>This topic describes IBM HTTP Server migration actions that you
can perform on your current (old) system. You do not need the z/OS
V2R1 level of code to make these changes, and the changes do not require
the z/OS V2R1 level of code to run once they are made.</p>
<p><a href="e0z3m100.htm#dt2mg404">Plan for the removal of support for IBM HTTP Server</a></p>
<h4 id="dt2mg701">Plan for the removal of support for IBM HTTP Server</h4><a id="idx1072"></a>
<p></p>
<p><strong>Description</strong>: z/OS
V2R1 is planned to be the last release to include the IBM HTTP Server
Powered by Domino (IHS powered by Domino ). IBM recommends you use
the IBM HTTP Server Powered by Apache, which is available in z/OS
Ported Tools as a replacement. IHS powered by Apache supports IPv6,
64-bit execution, and includes security authentication and authorization
capabilities similar to those provided in IHS powered by Domino .
Also, a refresh of IBM HTTP Server powered by Apache is planned later
in 2013. IBM plans to provide documentation help with customer migration
to IBM HTTP Server Powered by Apache.</p>
<table id="wq567" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>IBM
HTTP Server</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes,
if you use IBM HTTP Server.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<p>Remove support of IBM HTTP Server for releases of z/OS later than
z/OS V2R1.</p>
<p><strong>Reference information:</strong> 
See Statement of Direction????????</p>
<h3 id="dt2mg702">IBM HTTP Server actions to perform before the first IPL of
z/OS V2R1</h3>
<p>This topic describes IBM HTTP Server migration actions that you
can perform after you have installed z/OS V2R1 but before the first
time you IPL. These actions might require the z/OS V2R1 level of code to be installed but
do not require it to be active.</p>
<p>None.</p>
<h3 id="dt2mg703">IBM HTTP Server actions to perform after the first IPL of z/OS
V1R13</h3>
<p>This topic describes IBM HTTP Server migration actions that you
can perform only after you have IPLed z/OS V2R1. You need a running
z/OS V2R1 system to perform these actions.</p>
<p>None.</p>
<h2 id="dt2mg704">Infoprint Server migration actions</h2>
<p>This topic describes migration actions for optional feature Infoprint
Server.</p>
<h3 id="dt2mg705">Infoprint Server actions to perform before installing z/OS
V2R1</h3><a id="idx1073"></a>
<p>This topic describes Infoprint Server migration actions that you
can perform on your current (old) system. You do not need the z/OS V1R13 level of code to make
these changes, and the changes do not require the z/OS V1R13 level of code to run once they are
made.</p>
<p><a href="e0z3m100.htm#dt2mg412">Upgrade Java for Infoprint Server</a></p>
<p><a href="e0z3m100.htm#btemode">Migrate from IP PrintWay basic
mode to extended mode</a><a id="idx1074"></a><a id="idx1075"></a><a id="idx1076"></a><a id="idx1077"></a></p>
<h4 id="dt2mg707">Upgrade Java for Infoprint Server</h4><a id="idx1078"></a>
<p>Writer: Allida Shoning (Allida.Shoning@ricoh-usa.com)
Technical: Carl Kugler (Carl.Kugler@ricoh-usa.com)</p>
<p><strong>Description</strong>: In z/OS V2R1, Infoprint Server requires Java
V7. If the JAVA_HOME environment variable specifies the location of
an earlier version of Java, you must update the JAVA_HOME environment
variable.</p>
<table id="wq568" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS Infoprint Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use the Infoprint Central or IPP
Server components of Infoprint Server and you do not have Java V7
installed or you specify the JAVA_HOME environment variable.You are
using Infoprint Central if the <strong>start-daemons={ssid}</strong> attribute
is specified in the Infoprint Server configuration file You are using
the IPP Server if the <strong>start-daemons={ippd}</strong> attribute is specified
in the Infoprint Server configuration file. The configuration file's
default location is <samp class="xph">/etc/Printsrv/aopd.conf</samp>. However,
you might have specified a different location in environment variable
AOPCONF in the <strong>aopstart</strong> EXEC.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>One of these:

<ul>
<li>IBM 31-bit SDK for z/OS, Java Technology Edition, V7 (5655-W43)</li>
<li>IBM 64-bit SDK for z/OS, Java Technology Edition, V7 (5655-W44)</li></ul>

<p>The IPP Server requires the 31-bit version.</p></td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:
</p>
<ol type="1">
<li>Install one or both of these Java products:

<ul>
<li>IBM 31-bit SDK for z/OS, Java Technology Edition, V7 (5655-W43)</li>
<li>IBM 64-bit SDK for z/OS, Java Technology Edition, V7 (5655-W44)</li></ul>If you use the IPP Server, install the 31-bit version. If you
use Infoprint Central, you can install any version.</li>
<li>If you use the IPP Server, update the directory path specified
in the JAVA_HOME environment variable in the <strong>aopstart</strong> EXEC.
The IPP Server requires the 31-bit version of Java V7.</li>
<li>If you use Infoprint Central, update the directory path specified
in the JAVA_HOME environment variable in the z/OS HTTP Server environment
variables file <samp class="xph">httpd.envvars</samp>.</li></ol>
<div>
<div class="note-noindent" id="wq570">
<span class="notetitle">Note:</span> <span class="notebody">If you installed Java V7 in the default Java directories, you
do not need to specify the JAVA_HOME environment variable.</span></div></div>
<p><strong>Reference information:</strong> For information about Java products
for z/OS, see http://www-03.ibm.com/ systems/z/os/zos/tools/java/.</p>
<h4 id="btemode">Migrate from IP PrintWay basic
mode to extended mode</h4><a id="idx1079"></a><a id="idx1080"></a><a id="idx1081"></a>
<p><strong>Description</strong>: Since z/OS V1R5,
the IP PrintWay&trade; component
of Infoprint Server can operate in a mode called <em>IP PrintWay extended mode</em>. IP PrintWay extended mode uses the SYSOUT Application
Programming Interface (SAPI) to obtain output data sets from the JES
spool. IP PrintWay extended
mode provides better performance, improved usability, and additional
functions. For information about the enhancements and limitations
in extended mode, see <cite>z/OS Infoprint Server Customization</cite>.</p>
<p><em>IP PrintWay basic
mode</em> is the name used for the original IP PrintWay mode of operation. You can continue
to run IP PrintWay basic mode in z/OS V2R1. In future releases, IBM
will make enhancements only to IP PrintWay.</p>
<p>You can run IP PrintWay basic
mode and IP PrintWay extended
mode at the same time only if you make sure that IP PrintWay basic mode and IP PrintWay extended mode select different
print jobs from the JES spool to print. Otherwise, unpredictable results
can occur.</p>
<table id="wq571" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Infoprint Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>Basic mode was stabilized in z/OS V1R5. Extended mode was introduced in z/OS V1R5.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because it will become a
requirement in a future release.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td> 

<ul>
<li>If you use Infoprint Central to work with IP PrintWay extended mode print jobs and printers,
you need:  

<ul>
<li>An operating IBM HTTP Server
base element of z/OS</li>
<li>The XML Toolkit for z/OS V1.10
(5655-J51)</li>
<li>IBM 31-bit SDK for z/OS, Java Technology
Edition, V6 (5655-R31).</li>
<li>Microsoft Internet
Explorer 5.5, Netscape Navigator 7.0, or IBM Home
Page Reader 4.0 or later</li></ul></li>
<li>In addition to IBM 31-bit
SDK for z/OS, Java Technology Edition, V6 (5655-R31), one
of the following will also work: 

<ul>
<li>IBM 64-bit SDK for z/OS, Java Technology
Edition, V6 (5655-R32)</li>
<li>IBM 31-bit SDK for z/OS, Java 2
Technology Edition, V5 (5655-N98)</li>
<li>IBM 64-bit SDK for z/OS, Java 2
Technology Edition, V5 (5655-N99)</li></ul></li>
<li>To use IP PrintWay extended
mode to print to VTAM-controlled printers, Infoprint Coaxial Printer
Support for z/OS (5655-N62)
is required.</li></ul></td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>Use check INFOPRINT_PRINTWAY_MODE, available
with APAR OA26583, to determine if you are currently using IP PrintWay basic mode.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: See  in <cite>z/OS Infoprint Server Customization</cite>.</p>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li><cite>z/OS Infoprint Server Customization</cite> describes
the features and limitations of IP PrintWay extended
mode and how to customize IP PrintWay extended
mode. It also describes how to customize the common message log and
Infoprint Central.</li>
<li><cite>z/OS Infoprint Server Operation and Administration</cite> describes
how to log in to Infoprint Central and how to view messages in the
common message log. It also describes how to modify printer definitions
for IP PrintWay extended
mode.</li>
<li><cite>z/OS Infoprint Server User&amp;apos;s Guide</cite> describes
considerations for submitting print jobs when you use IP PrintWay extended mode.</li>
<li><cite>z/OS Infoprint Server Messages and Diagnosis</cite> describes
how to trace IP PrintWay extended
mode.</li>
<li>The Infoprint Central online help system describes how to use
Infoprint Central.</li></ul>
<h3 id="dt2mg709">Infoprint Server actions to perform before the first IPL of
z/OS V2R1</h3>
<p>This topic describes Infoprint Server migration actions that you
can perform after you have installed z/OS V2R1
but before the first time you IPL. These actions might require the z/OS V2R1 level of code to be installed
but do not require it to be active.</p>
<p><a href="e0z3m100.htm#ai3svco1">Remount the Printer Inventory and copy files that were customized</a></p>
<p><a href="e0z3m100.htm#regsizeao">Update or remove the region size in the AOPSTART startup procedure</a></p>
<h4 id="ai3svco1">Remount the Printer Inventory and copy files that were customized</h4><a id="idx1082"></a><a id="idx1083"></a><a id="idx1084"></a><a id="idx1085"></a><a id="idx1086"></a><a id="idx1087"></a>
<p><strong>Description</strong>: When migrating to z/OS V1R13 Infoprint Server, you
must bring forward the customized data from your previous system. <a id="idx1088"></a><a id="idx1089"></a><a id="idx1090"></a></p>
<table id="wq572" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Infoprint Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 

</p>
<ul>
<li><em>Printer Inventory</em>:


<ul>
<li>Remount the <samp class="xph">/var/Printsrv</samp> directory from the z/OS V1R12
system on the z/OS V1R13 system.
The <samp class="xph">/var/Printsrv</samp> directory contains the Printer Inventory
as well as other Infoprint Server files. The default directory is <samp class="xph">/var/Printsrv</samp>.
However, you might have changed the directory name in the base-directory
attribute in the <samp class="xph">aopd.conf</samp> configuration file.

<div>
<div class="note-noindent" id="wq573">
<span class="notetitle">Note:</span> <span class="notebody">
<ol type="1">
<li>After you start Infoprint Server on the z/OS system, you should use the Infoprint Server <strong>pidu</strong> command to export the Printer Inventory on
the z/OS V1R13 system so that
you have a backup of the Printer Inventory.</li>
<li>If <samp class="xph">/var/Printsrv</samp> is not mounted at a separate mount
point, use the Infoprint Server <strong>pidu</strong> command
to export the Printer Inventory on the original system and restore
it on the z/OS V1R13 system.
Do not use other copy commands to copy the Printer Inventory. (Mounting
/var/Printsrv at a separate mount point can result in better management
of disk space and easier migration.)</li></ol></span></div></div></li>
<li>Configure the Infoprint Server environment variables (for example,
AOPCONF, PATH, LIBPATH, NLSPATH, MANPATH) in <samp class="xph">/etc/profile</samp>.</li></ul></li>
<li><em>Configuration file</em>: If you modified the
Infoprint Server configuration file, copy the file to the z/OS V1R13 system. Its default
location is <samp class="xph">/etc/Printsrv/aopd.conf</samp>. However, you might
have specified a different location in environment variable AOPCONF.</li>
<li><strong><span class="bold-italic">aopstart</span></strong> <em>EXEC</em>:
If you modified the <strong>aopstart</strong> EXEC, copy
it to the z/OS V1R13 system.</li>
<li><em>IP PrintWay</em>:
If you currently use the IP PrintWay component
of Infoprint Server, copy to the z/OS V1R13
system any IP PrintWay exit
routines and data stream filters you have written. <span>It
is a good practice to recompile the exits and filters on z/OS V1R13.</span></li>
<li><em>NetSpool</em>: If you currently use the NetSpool component
of Infoprint Server, copy to the z/OS V1R13
system any NetSpool exit
routines you have written. <span>It is a good practice to recompile
the exits and filters on z/OS V1R13.</span></li>
<li><em>Print Interface</em>: If you currently use
the Print Interface component of Infoprint Server, take these actions:


<ul>
<li>If you have written any data stream filters, copy them to the z/OS V1R13 system. You do not need
to recompile them.</li>
<li>If you run the SAP R/3 application server on the z/OS system, copy the SAP callback daemon configuration
file to the z/OS V1R13 system.
Its default location is <samp class="xph">/etc/Printsrv/aopsapd.conf</samp>. However,
you might have specified a different location in environment variable
AOPSAPD_CONF.</li></ul></li>
<li><em>Infoprint Central</em>: If you currently use
Infoprint Central, copy the z/OS HTTP
Server configuration and environment variables files to the z/OS V1R13 system. The default
locations of these files are <samp class="xph">/etc/httpd.conf</samp> and <samp class="xph">/etc/httpd.envvars</samp>.</li></ul>
<p><strong>Reference information</strong>: <cite>z/OS Infoprint Server Customization</cite>.</p>
<h4 id="regsizeao">Update or remove the region size in the AOPSTART startup procedure</h4>
<p>[[[[ Contributing writer: Allida Shoning/US/InfoPrint/IDE@IBMUS
]]] [[[[ Technical contacts: Steve Luerman/US/InfoPrint/IDE@IBMUS,
Carl Kugler/US/InfoPrint/IDE@IBMUS ]]]]</p>
<p><strong>Description</strong>: Starting with z/OS V1R13, the Infoprint Server
startup procedure AOPSTART specifies a region size of 512 megabytes.
Before z/OS V1R13, AOPSTART did not specify a region size, so the
default region size defined for your installation was used.</p>
<p>Because the default region size might not be sufficient to use
all the functions that Infoprint Server provides, it is a good practice
to specify a region size on the startup procedure. However, if you
want to continue to use the default region size or a region size other
than 512 megabytes, edit the AOPSTART procedure to remove the region
specification. If you have customized the AOPSTART procedure, you
can continue to use the customized version.<a id="idx1091"></a><a id="idx1092"></a><a id="idx1093"></a></p>
<table id="wq575" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Infoprint Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use the AOPSTART procedure that
IBM provides and want to continue to use the default region size used
in releases prior to z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Modify the EXEC statement in the AOPSTART procedure to remove
or alter the REGION parameter: 
<pre class="xmp"><code>//AOPSTART EXEC PGM=AOPBATCH,PARM='//usr/lpp/Printsrv/bin/aopstart',
//             REGION=512M,
//             TIME=NOLIMIT</code></pre></li>
<li>Save the AOPSTART procedure.</li></ol>
<p><strong>Tips</strong>: 
</p>
<ul>
<li>The AOPSTART procedure is distributed in SYS1.IBM.PROCLIB. However,
during installation it might have been copied to another data set
in the started task PROCLIB concatenation.</li>
<li>Specify a region size of at least 256 MB if you start the Infoprint
Server Transform Manager to run data stream transforms. <span>(This
tip also applies to releases before z/OS V1R13.)</span></li>
<li>Specify a region size of at least 200 MB if you start the Infoprint
Server IPP Server to receive print requests from IPP-enabled clients. <span>(This tip also applies to releases before z/OS V1R13.)</span></li>
<li>User exits, such as IEFUSI, can modify the region size of an address
space. Do not alter the region size of address spaces in the OMVS
subsystem category.<a id="idx1094"></a><a id="idx1095"></a></li></ul>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li>For information about the AOPSTART procedure, see <cite>z/OS Infoprint Server Customization</cite>.</li>
<li>For more information about the IEFUSI exit, see <cite>z/OS MVS Installation Exits</cite>.</li></ul>
<h3 id="dt2mg712">Infoprint Server actions to perform after the first IPL of
z/OS V2R1</h3>
<p>This topic describes Infoprint Server migration actions that you
can perform only after you have IPLed z/OS V2R1.
You need a running z/OS V2R1
system to perform these actions.</p>
<p><a href="./runaops.html">Run aopsetup</a></p>
<h4 id="runaops1">Run aopsetup</h4><a id="idx1096"></a><a id="idx1097"></a><a id="idx1098"></a><a id="idx1099"></a><a id="idx1100"></a><a id="idx1101"></a><a id="idx1102"></a>
<p><strong>Description</strong>: When migrating to z/OS V2R1 Infoprint Server,
you must run the <strong>aopsetup</strong> shell script to establish the correct
file permissions for Infoprint Server directories and files.</p>
<table id="wq577" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Infoprint Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Run the <strong>aopsetup</strong> shell script from
an rlogin shell, from an OMVS session, or with the BPXBATCH command.
Specify the names of the RACF groups
that you defined for Infoprint Server operators and administrators
as arguments to <strong>aopsetup</strong>. For example, if you defined group
AOPOPER for operators and group AOPADMIN for administrators, enter:
  </p>
<pre class="xmp"><code>/usr/lpp/Printsrv/bin/aopsetup AOPOPER AOPADMIN</code></pre>
<p><strong>Rule</strong>: You must run <strong>aopsetup</strong> from a user ID with a
UID of 0. You can use the <strong>su</strong> command to switch to an effective
UID of 0 if you have READ access to the BPX.SUPERUSER profile in the RACF FACILITY class.</p>
<p><strong>Tip</strong>: You can run <strong>aopsetup</strong> from the driving system
(instead of the target system) if all of these are true: 
</p>
<ul>
<li>You have the target system's <samp class="xph">/var/Printsrv</samp> directory
accessible.</li>
<li>You reference the target system's <samp class="xph">/usr/lpp/Printsrv</samp> directory
mounted under a <samp class="xph">/service</samp> directory as described in
the comments at the beginning of the <strong>aopsetup</strong> shell script.</li>
<li>The RACF database groups
for operators and administrators are the same on the driving and target
system.</li></ul>
<p><strong>Reference information</strong>: For details about , see <cite>z/OS Infoprint Server Customization</cite>.</p>
<h2 id="dt2mg716">JES2 migration actions</h2>
<p>This topic describes migration actions for base element JES2.</p>
<h3 id="e0z3m100-gen120">JES2 actions to perform before installing z/OS V2R1</h3><a id="idx1103"></a>
<p>This topic describes JES2 migration actions that you can perform
on your current (old) system. You do not need the z/OS V2R1 level of code to make these changes,
and the changes do not require the z/OS V2R1
level of code to run once they are made.</p>
<p>None.<a id="idx1104"></a><a id="idx1105"></a><a id="idx1106"></a><a id="idx1107"></a></p>
<p><a href="e0z3m100.htm#jes2jobmod">Change JESJOBS profiles</a></p>
<h4 id="dt2mg717">Change JESJOBS profiles</h4><a id="idx1108"></a><a id="idx1109"></a><a id="idx1110"></a>
<p></p>
<p>[[[[ Writer: Joshua Horton/Poughkeepsie/IBM
... Technical contact: Tom Wasik/Poughkeepsie/IBM ]]]]</p>
<p><strong>Description</strong>: In z/OS V2R1, the new Job Modify SSI 85 defines
additional resource names to the JESJOBS class. If any existing JESJOBS
entity name matches one of the new resource names, it could result
in unintended user authorization to modify job attributes. If necessary,
update your JESJOBS profiles to avoid granting unintended user authority
to modify jobs.</p>
<table id="wq578" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS JES2.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12 or z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if JESJOBS profiles could
grant unintended authority to modify jobs.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ol type="1">
<li>Search for JESJOBS profile names which match any of the new JESJOBS
resource names.</li>
<li>Ensure that your existing JESJOBS profiles grant the intended
authority, given the new use of JESJOBS by the Job Modify SSI 85.</li>
<li>If any JESJOBS profile inadvertently allows user authority to
Job Modify SSI 85 actions, update the profile or create a new profile,
if necessary.</li></ol>
<p><strong>Reference information:</strong> 
</p>
<ul>
<li><cite>z/OS JES2 Initialization and Tuning Guide</cite></li>
<li><cite>z/OS Security Server RACF Security Administrator&amp;apos;s Guide</cite>i</li>
<li><cite>z/OS Planning for Multilevel Security and
the Common Criteria</cite></li></ul><p class="indatacontent">.</p>
<h3 id="dt2mg718">JES2 actions to perform before the first IPL of z/OS V2R1</h3>
<p>This topic describes JES2 migration actions that you can perform
after you have installed z/OS V2R1 but before the first time you IPL.
These actions might require the z/OS V2R1 level of code to be installed
but do not require it to be active.</p>
<p>None.</p>
<h3 id="e0z3m100-gen122">JES2 actions to perform after the first IPL of z/OS V2R1</h3>
<p>This topic describes JES2 migration actions that you can perform
only after you have IPLed z/OS V2R1.
You need a running z/OS V2R1
system to perform these actions. <a id="idx1111"></a><a id="idx1112"></a><a id="idx1113"></a><a id="idx1114"></a><a id="idx1115"></a><a id="idx1116"></a></p>
<p><a href="e0z3m100.htm#jes2brodcast">Remove BRODCAST= from the OUTDEF initialization statement</a></p>
<p><a href="e0z3m100.htm#jes2jclerr">Remove JCLERR= from the JOBDEF initialization statement</a></p>
<p><a href="e0z3m100.htm#activ11">Activate z11 mode</a></p>
<h4 id="dt2mg720">Remove BRODCAST= from the OUTDEF initialization statement</h4><a id="idx1117"></a><a id="idx1118"></a>
<p></p>
<p>[[[[ Writer: Joshua Horton/Poughkeepsie/IBM
... Technical contact: Tom Wasik/Poughkeepsie/IBM ]]]]</p>
<p><strong>Description</strong>: In z/OS 2.1, JES2 ignores any specifications
of the BRODCAST= parameter. TSO notify messages are sent to the user,
or are issued locally if the user is not logged on. You can no longer
use BRODCAST= to specify where TSO notify messages are sent.</p>
<table id="wq580" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS JES2.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12 or z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to avoid warning messages.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ol type="1">
<li>Check the OUTDEF statement in the JES2 initialization deck for
BRODCAST= specifications.</li>
<li>Remove BRODCAST= specifications from the OUTDEF statement.</li></ol>
<p><strong>Reference information:</strong> 
</p>
<ul>
<li><cite>z/OS JES2 Messages</cite></li>
<li><cite>z/OS JES2 Initialization and Tuning Reference</cite></li>
<li><cite>z/OS JES2 Diagnosis</cite></li></ul><em>JES2 Messages, JES2 Initialization and Tuning Reference, JES2
Commands, JES2 Diagnosis</em><p class="indatacontent">.</p>
<h4 id="dt2mg721">Remove JCLERR= from the JOBDEF initialization statement</h4><a id="idx1119"></a><a id="idx1120"></a>
<p></p>
<p>[[[[ Writer: Joshua Horton/Poughkeepsie/IBM
... Technical contact: Tow Wasik/Poughkeepsie/IBM ]]]]</p>
<p><strong>Description</strong>: In z/OS V2R1, JES2 ignores any specifications
of the JCLERR= parameter. If an error on the JOB card is encountered
during the INPUT phase, the job is sent to the converter for INPUT
phase error message processing. You can no longer use JCLERR= to specify
for the job to be failed under these conditions.</p>
<table id="wq582" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS JES2.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12 or z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V2R1..</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to avoid warning messages.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ol type="1">
<li>Check the JOBDEF statement in the JES2 initialization deck for
JCLERR= specifications.</li>
<li>Remove any JCLERR= specifications from the JOBDEF statement.</li></ol>
<p><strong>Reference information:</strong> 
</p>
<ul>
<li><cite>z/OS JES2 Messages</cite></li>
<li><cite>z/OS JES2 Initialization and Tuning Reference</cite></li>
<li><cite>z/OS JES2 Diagnosis</cite></li>
<li><cite>z/OS JES2 Commands</cite></li></ul><p class="indatacontent">.</p>
<h4 id="activ11">Activate z11 mode</h4>
<p>[[[[ Contributing writer: Joshua Horton/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Dave Novey/Rochester/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: If you wish to take advantage of the
full-function level of JES2, you must be in z11 mode. Activating z11
mode upgrades the JES2 checkpoint and enables JES2 functionality that
was introduced in z/OS V1R11,
including JOE data area extensions supported by BERTs. For more information
on the JES2 functionality, see the reference links below. <a id="idx1121"></a><a id="idx1122"></a></p>
<table id="wq584" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>JES2.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.
See IBM United States Software Announcement 212-086, dated April 11,
2012</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12 JES2.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because it will be a requirement
in the release following z/OS V2R1. (IBM United States Software Announcement
212-086, dated April 11, 2012).</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>In order to activate z11 mode, all systems in
the JES2 MAS must be at z/OS V2R1
or later. You may fall back to z2 mode, if necessary.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>Use check <strong>JES2_Z11_Upgrade_CK_JES2</strong> to
determine if your system is ready to upgrade the JES2 checkpoint to
z11 mode. For more information, see <cite>IBM Health Checker for z/OS: User's Guide</cite>.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ul>
<li>After migrating to z/OS V1R11
JES2, or later, on all systems in your MAS, determine your z11 checkpoint
activation readiness: 

<ol type="1">
<li>Use the <span class="synph"><span class="kwd">$D ACTIVATE </span></span>command. This command
indicates if activation to z11 mode will succeed.</li>
<li>Review your current utilization of BERT data to determine if there
are sufficient BERTS, as detailed in <a href="e0z3m100.htm#checkbert">Check BERT utilization</a>.</li>
<li>If you issue the <span class="synph"><span class="kwd">$ACTIVATE,LEVEL=z11</span></span> command,
activation of LARGEDS support is required.</li>
<li>An additional <span class="synph"><span class="var">nnn</span></span> 4K records
for CKPT1 is required for z11 mode.</li></ol></li>
<li>Run the <span class="synph"><span class="kwd">JES2 $ACTIVATE</span></span> command <span>to
verify non-configuration changes that must be accommodated before
going to z11,</span> and to activate z11 mode following the considerations
for this command found in <cite>z/OS JES2 Commands</cite>. 
<div>
<div class="note-noindent" id="wq586">
<span class="notetitle">Note:</span> <span class="notebody">The
SPOOLDEF LARGEDS=FAIL (default value) in JES2PARM parmlib member is
not supported in z11 mode. In z11 mode, on a COLD start, JES2 defaults
to LARGEDS=ALLOWED. However, you cannot issue the $ACTIVATE,LEVEL=z11
command in the environment of SPOOLDEF LARGEDS=FAIL.</span></div></div></li></ul>
<p>By default, JES2 restarts in the same mode (z2 or z11) as other
members of the MAS (if any are active) or the mode the last active
JES2 member was in when it came down. To restart JES2 in z2 mode,
specify UNACT on PARM=.  On a cold start JES2 starts in z11 mode unless
overridden by OPTSDEF COLD_START_MODE or UNACT parameter.</p>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li>For a list of the enhancements introduced in z/OS V1R11 for z11 mode, see <cite>z/OS Introduction and Release Guide</cite>.</li>
<li>For $ACTIVATE, $D ACTIVATE, $D CKPTSPACE and $JD HISTORY command
details, see <cite>z/OS JES2 Commands</cite>.</li></ul>
<h5 id="checkbert">Check BERT utilization</h5>
<p>Before issuing the $ACTIVATE,LEVEL=z11 command, review the current
utilization of BERT data to determine whether there are sufficient
BERTs. Additional BERTs are needed for each SYSOUT data set that has
transaction data associated with it. These SYSOUT data sets can be
seen using SDSF by setting APPC ON and examining SYSOUT data sets
on the H and O panels; SYSOUT data sets with transaction data have
nontraditional JES2 job IDs. Consider increasing the number of BERTs
to correspond to two times the maximum number of transaction SYSOUT
data sets on the system. BERT utilization should be monitored after
the $ACTIVATE to z11 mode to ensure there are sufficient BERTs for
the jobs and SYSOUT in the MAS. There are several ways to determine
your current BERT usage.

</p>
<ul>
<li>The $D CKPTSPACE,BERTUSE command displays a table of the types
of control blocks in BERTs and how many BERTs are used by each control
block type. The example below shows the output of the command:

<pre class="xmp"><code>$HASP852 CKPTSPACE  CURRENT BERT UTILIZATION
$HASP852            TYPE         COUNT  CB COUNT
$HASP852            -------- --------- ---------
$HASP852            INTERNAL        11         1,
$HASP852            JQE            211       108,
$HASP852            CAT            114        38,
$HASP852            WSCQ             1         1,
$HASP852            DJBQ             0         0,
$HASP852            JOE              0         0,
$HASP852            FREE           763         0</code></pre>
In the example,
there are 108 JQEs that have a total of 211 BERTs associated with
them. This example is for a system in z2 mode and does not have any
BERTs associated with JOEs.</li>
<li>The $D ACTIVATE command displays the number of BERTs that are
needed for activation to z11 mode. This is the number of BERTs that
will be associated with JOEs after the $ACTIVATE. The example below
shows the output of the $D ACTIVATE command:       

<pre class="xmp"><code>$HASP895 $DACTIVATE
$HASP895 JES2 CHECKPOINT MODE IS CURRENTLY Z2
$HASP895 THE CURRENT CHECKPOINT:
$HASP895  -- CONTAINS 1100 BERTS AND BERT UTILIZATION IS 30
$HASP895     PERCENT.
$HASP895  -- CONTAINS 158 4K RECORDS.
$HASP895 z11 CHECKPOINT MODE ACTIVATION WILL:
$HASP895  -- EXPAND CHECKPOINT SIZE TO 165 4K RECORDS.
$HASP895  -- REQUIRE 22 ADDITIONAL BERTS AND UTILIZATION
$HASP895     WOULD REACH 32 PERCENT.
$HASP895 z11 ACTIVATION WILL SUCCEED IF ISSUED FROM THIS MEMBER.</code></pre>
In
the example, there are 22 additional BERTs that will be used after
the $ACTIVATE to z11 mode, for transaction data associated with JOEs.

<div>
<div class="note-noindent" id="wq587">
<span class="notetitle">Note:</span> <span class="notebody">When the SPOOLDEF LARGEDS=FAIL (default value) is in effect
in your JES2PARM parmlib member, the following message will be issued
by the $ACTIVATE command:

<pre class="xmp"><code>$HASP895 z11 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER.
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION: 
$HASP895     -- LARGEDS SUPPORT MUST BE ACTIVATED.</code></pre></span></div></div></li>
<li>A general history of BERT usage can be obtained by using the $JD
HISTORY(BERT) command or by using the SDSF RM panel. This displays
the usage of BERTs after the system was IPLed. The example below shows
the output of the $JD HISTORY(BERT) command: 

<pre class="xmp"><code>$HASP9130 D HISTORY
$HASP9131 JES2 BERT     USAGE HISTORY
DATE     TIME        LIMIT    USAGE      LOW     HIGH  AVERAGE
-------- -------- -------- -------- -------- -------- --------
2009.086 16:00:00     1100      337      337      337      337
2009.086 15:50:09     1100      337      125      337      192</code></pre></li></ul>
<h2 id="dt2mg724">JES3 migration actions</h2>
<p>This topic describes migration actions for optional feature JES3.</p>
<h3 id="dt2mg725">JES3 actions to perform before installing z/OS V2R1</h3><a id="idx1123"></a>
<p>This topic describes JES3 migration actions that you can perform
on your current (old) system. You do not need the z/OS V2R1 level of code to make these changes,
and the changes do not require the z/OS V2R1
level of code to run once they are made.<a id="idx1124"></a><a id="idx1125"></a><a id="idx1126"></a><a id="idx1127"></a></p>
<p>None.</p>
<h3 id="dt2mg726">JES3 actions to perform before the first IPL of z/OS V2R1</h3>
<p>This topic describes JES3 migration actions that you can perform
after you have installed z/OS V2R1
but before the first time you IPL. These actions might require the z/OS V2R1 level of code to be installed
but do not require it to be active.<a id="idx1128"></a><a id="idx1129"></a><a id="idx1130"></a><a id="idx1131"></a><a id="idx1132"></a><a id="idx1133"></a></p>
<p><a href="e0z3m100.htm#jes3relform">Change JES3 release level format</a></p>
<p><a href="e0z3m100.htm#dlogsplit1">Modify code that depends on the format of suppressed split
messages in the DLOG</a></p>
<p><a href="e0z3m100.htm#moddatlorec">Modify code that uses DATLOREC and DATINPTR (IATYDAT) as a
 programming interface</a></p>
<p><a href="e0z3m100.htm#autoflsh">Avoid redundant *S main,FLUSH command in response to XCF messages</a></p>
<p><a href="e0z3m100.htm#jes3msg">Update automation that handles message IAT3100</a></p>
<h4 id="dt2mg730">Change JES3 release level format</h4><a id="idx1134"></a><a id="idx1135"></a><a id="idx1136"></a><a id="idx1137"></a>
<p></p>
<p>[[[[ Writer: Joshua Horton/Poughkeepsie/IBM
... Technical contact: John Edwards/Rochester/IBM ]]]]</p>
<p><strong>Description</strong>: In z/OS V2R1 SSI 54, SSI 82 and SSI 83 report
the JES3 release level using the JES2 format 'z/OS 2.1'.  In previous
versions of z/OS, JES3 reported the release level using the format
'z 1.13.0'. The SSI fields which are affected by the format change
are: 
</p>
<ul>
<li>SSI 54: SSVIVERS field from macro IEFSSVI</li>
<li>SSI 82: JPXVERSN field from macro IAZJPLEX</li>
<li>SSI 83: JPSYVERN field from macro IAZJPLXI.</li></ul>
<table id="wq588" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS JES3.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R12 or z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if code is dependent on the JES3 release
level returned by SSI 54, SSI 82 or SSI 83.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ol type="1">
<li>Search for fields SSVIVERS, JPXVERSN and JPSYVERN in invocations
of SSI 54, SSI 82 and SSI 83.</li>
<li>For any code that requires the z/OS 2.1 JES3 release level, change
the expected format to 'z/OS 2.1' (z/OS #.#).</li></ol>
<p><strong>Reference information:</strong> <cite>z/OS MVS Using the Subsystem Interface</cite>..</p>
<h4 id="dlogsplit1">Modify code that depends on the format of suppressed split
messages in the DLOG</h4>
<p>[[[[ Contributing writer: Joshua Horton/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Rich Jirsa/Rochester/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: The JES3 DLOG facility was introduced for tracking
all message activity in a sysplex. It uses an MCS extended console
to receive the messages and reformats them in the JES3 format. When
these messages are longer than can be formatted into a single line,
they are split into two lines. Before z/OS V1R13 JES3, longer messages
having a receive ID were formatted differently if they were suppressed
by the message processing facility (MPF).  Beginning with z/OS V1R13
JES3, all suppressed messages with a receive ID are split in the same
manner.</p>
<p>The following DLOG excerpt shows how a suppressed message (XXX100I)
was split prior to z/OS V1R13 JES3: </p>
<pre class="xmp"><code>          10250 1143599  SY1 R= XXX33913 ICH70001I IBMUSER  LAST ACCESS AT 11:39:46 ON MONDAY, NOVEMBER 1, 2010
          10250 1144001  SY1 R= XXX33913 IEF403I XXX33913 - STARTED - TIME=11.44.00
MLG       10250 1144004 &amp;SY1 R= XXX33913 +XXX100I 9012345678901234567890123456
MLG       10250 1144004 &amp;SY1 R= XXX3391378901234567890123456789012345678901234567890123456789012345
          10250 1144004  SY1 R= XXX33913 IEF404I XXX33913 - ENDED - TIME=11.44.00</code></pre><p class="indatacontent"> The
following DLOG excerpt shows how a suppressed message (XXX100I) is
split beginning with z/OS V1R13 JES3: </p>
<pre class="xmp"><code>          10305 1000486  SY1 R= XXX33913 ICH70001I IBMUSER  LAST ACCESS AT 09:57:46 ON MONDAY, NOVEMBER 1, 2010
          10305 1000488  SY1 R= XXX33913 IEF403I XXX33913 - STARTED - TIME=10.00.48
MLG       10305 1000494 &amp;SY1 R= XXX33913 +XXX100I 9012345678901234567890123456
MLG       10305 1000494 &amp;SY1 R= XXX33913 78901234567890123456789012345678901234567890123456789012345
          10305 1000494  SY1 R= XXX33913 IEF404I XXX33913 - ENDED - TIME=10.00.49   </code></pre><a id="idx1138"></a><a id="idx1139"></a>
<table id="wq590" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>JES3.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13 JES3.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12 JES3.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your installation has a code dependency
on the format of messages in the JES3 DLOG.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Ensure that any dependency on DLOG message
formats are examined and corrected.</p>
<p><strong>Reference information</strong>: For more information, see the "Message
Format" chapter in <cite>z/OS JES3 Messages</cite>.</p>
<h4 id="moddatlorec">Modify code that uses DATLOREC and DATINPTR (IATYDAT) as a
 programming interface</h4>
<p>[[[[ Technical contacts: John Edwards/Rochester/IBM,
Rich Jirsa/Rochester/IBM ]]]]</p>
<p><strong>Description</strong>: When a job's JCL contains in-stream data sets,
the  in-stream data is stored in multi-record files apart from the
JESJCLIN file.  These files are located by SYSIN pointer records that
are written into a job's JESJCLIN file by input service.  Prior  to
z/OS V1R12 (without APAR OA34642), SYSIN pointer records were included
in the JESJCLIN file's record count which is saved in DATLOREC (IATYDAT).
 In z/OS V1R12, z/OS V1R11, and z/OS V1R10 (with APAR<span> OA33040</span>),
the SYSIN pointer records were not included  in the record count for
JESJCLIN files.  <span>With APAR OA34642 applied,</span> a new
flag, DATCTLRD (IATYDAT),  will be on for any record, including SYSIN
pointer records, that are not included in a file's record count.  <a id="idx1140"></a><a id="idx1141"></a></p>
<table id="wq591" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>JES3.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R12 JES3, z/OS V1R11 JES3, and z/OS V1R10
JES3 with the PTF for APAR OA34642 applied.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12 JES3 without the PTF for APAR OA34642
applied.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use DATLOREC and DATINPTR (IATYDAT)
as a programming interface.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Before applying the PTF for APAR OA34642,
examine and modify any code that uses DATLOREC and DATINPTR (IATYDAT)
as a programming interface.  Note that IATYDAT is an internal JES3
control block that resides on spool and that this change affects only
JESJCLIN data sets.</p>
<p><strong>Reference information</strong>: For more information, see <cite>z/OS JES3 Initialization and Tuning Guide</cite>.</p>
<h4 id="autoflsh">Avoid redundant *S main,FLUSH command in response to XCF messages</h4>
<p>[[[[ Contributing writer: Joshua Horton/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Peter Kania/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Prior to z/OS V1R13, a DOWN response to message
IXC102A issued for a JES3 local processor required operations to enter
the <span class="synph"><span class="kwd">*S main,FLUSH</span></span> command. Without the <span class="synph"><span class="kwd">*S
main,FLUSH</span></span> command, jobs on the local were held up until
the local processor was reconnected.</p>
<p>Starting in z/OS V1R13, JES3 flushes the active jobs on
the local processor automatically as soon as the operator responds
to message IXC102A. This automatic flush eliminates the step of issuing
the command and reduces the time gap between the local processor being
removed from the sysplex and job recovery actions.</p>
<p>In z/OS V1R13 JES3 and later releases, if you run the <span class="synph"><span class="kwd">*S
main,FLUSH</span></span> command in response to the XCF messages,
the command will have no effect because the affected jobs will have
already been flushed by the new automatic processing.</p>
<p><a id="idx1142"></a><a id="idx1143"></a></p>
<table id="wq592" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>JES3.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12 JES3</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to avoid redundant <span class="synph"><span class="kwd">*S
main,FLUSH</span></span> commands.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If you want to avoid redundant <span class="synph"><span class="kwd">*S
main,FLUSH</span></span> commands, remove the <span class="synph"><span class="kwd">*S main,FLUSH</span></span> command
from all automated procedures or operating procedures.</p>
<p><strong>Reference information</strong>: <cite>z/OS JES3 Messages</cite>.</p>
<h4 id="jes3msg">Update automation that handles message IAT3100</h4>
<p>[[[[ Technical contacts:Paul Rieth/Endicott/IBM
]]]]</p>
<p><strong>Description</strong>: In the text of message IAT3100, a space has
been added between the "z" and the release identifier. In z/OS V1R12,
the text for message IAT3100 appeared as in the following example: </p>
<pre class="xmp"><code>IAT3100 JES3 z1.12.0   SYSTEM  HOTSTART ON 2011.304 AS SY1 </code></pre><p class="indatacontent"> Starting
with z/OS V1R13, the text appears as in the following example: </p>
<pre class="xmp"><code>IAT3100 JES3 z 1.13.0  SYSTEM  HOTSTART ON 2011.304 AS SY1   </code></pre><p class="indatacontent"> If
your message automation for JES3 depends on the message text instead
of the message number, your JES3 automation routines might be affected.<a id="idx1144"></a><a id="idx1145"></a><a id="idx1146"></a></p>
<table id="wq593" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>JES3.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13 JES3.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12 JES3.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have automation routines that examine
the message text instead of the message number.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Change your automation routines to account
for the additional space.</p>
<p><strong>Reference information</strong>: For more information, see <cite>z/OS JES3 Messages</cite>.</p>
<h3 id="dt2mg731">JES3 actions to perform after the first IPL of z/OS V2R1</h3>
<p>This topic describes JES3 migration actions that you can perform
only after you have IPLed z/OS V2R1. You need a running z/OS V2R1
system to perform these actions.</p>
<p>None.</p>
<h2 id="am1lenv1">Language
Environment migration actions</h2>
<p>This topic describes migration actions for base element Language Environment.</p>
<h3 id="e0z3m100-gen126">Language
Environment actions to perform before installing z/OS V2R1</h3><a id="idx1147"></a>
<p>This topic describes Language Environment migration actions that
you can perform on your current (old) system. You do not need the
z/OS V2R1 level of code to make these changes, and the changes do
not require the z/OS V2R1 level of code to run once they are made.</p>
<p>None.</p>
<h3 id="e0z3m100-gen127">Language
Environment actions to perform before the first IPL of z/OS V2R1</h3>
<p>This topic describes Language
Environment migration actions that you can perform after you
have installed z/OS V2R1 but
before the first time you IPL. These actions might require the z/OS V2R1 level of code to be installed
but do not require it to be active.</p>
<p><a href="e0z3m100.htm#am3le2a1">Update the CSD based on the newest CEECCSD</a></p>
<p><a href="e0z3m100.htm#am3le2b1">Update Language
Environment load modules in the LPA</a></p>
<p><a href="e0z3m100.htm#regionjcl">Determine if the region-level runtime option JCL requires changes</a></p>
<p><a href="e0z3m100.htm#e0z3m100-gen55">Accommodate removals associated with setting the system-level
default runtime option in assembler modules</a></p>
<p><a href="e0z3m100.htm#ceeprmset">Convert to CEEPRMxx to set system-level default runtime options</a></p>
<p><a href="e0z3m100.htm#ceeprmxx">Migrate to the CEEPRMxx parmlib support</a></p>
<h4 id="am3le2a1">Update the CSD based on the newest CEECCSD</h4>
<p><strong>Description</strong>: Each release, Language Environment adds or
deletes load modules in the CICS system
definition (CSD) file. Thus, you should update the file each release
using the program definitions found in members CEECCSD and CEECCSDX
found in the SCEESAMP data set. <span>The CSD samples provided
by Language Environment (CEECCSD and CEECCSDX) at the latest release
may be used for systems at lower releases that can co-exist with this
level of z/OS.</span></p>
<table id="wq594" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx1148"></a><a id="idx1149"></a><strong>Element or feature</strong>:</td>
<td>Language
Environment.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use CICS.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>CICS.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Update the CSD file using the program
definitions in member CEECCSD (and member CEECCSDX if using CICS TS
V3) found in the hlq.SCEESAMP data set. </p>
<div>
<div class="note-noindent" id="wq595">
<span class="notetitle">Note:</span> <span class="notebody"> The group containing
the Language Environment runtime routines must be in the group list
used during CICS startup.</span></div></div>
<p><strong>Reference information</strong>: See <cite>z/OS Language Environment Runtime Application Migration Guide</cite></p>
<h4 id="am3le2b1">Update Language
Environment load modules in the LPA</h4>
<p><strong>Description</strong>: Each release you must update
the Language Environment load
modules that you make accessible through the link pack area (LPA).
In addition, each release you should review your list of Language Environment load
modules in the LPA to determine if it's still suitable. <a id="idx1150"></a><a id="idx1151"></a></p>
<table id="wq596" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Language
Environment.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you need to make modules accessible
through the link pack area (LPA).</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Review Language Environment load
modules in the LPA.</p>
<p>To move load modules into the LPA, use the following sample members
in the CEE.SCEESAMP data set:

</p>
<ul>
<li><em>AFHWMLP2</em>: This is a sample of all Language Environment Fortran
component modules eligible for the LPA.</li>
<li><em>CEEWLPA</em>: This is a sample of a PROG<span class="synph"><span class="var">xx</span></span> member
of SYS1.PARMLIB that includes all Language Environment CEE-prefixed runtime modules
eligible for the LPA (that is, all Language Environment base modules) except the callable
services stubs.</li>
<li><em>CELQWLPA</em>: This is a sample for AMODE 64
runtime support.</li>
<li><em>EDCWLPA</em>: This is a sample of a PROG<span class="synph"><span class="var">xx</span></span> member
of SYS1.PARMLIB that includes all Language Environment EDC-prefixed and CEH-prefixed
runtime modules eligible for the LPA (that is, all XL C/C++ component
modules) except locales and code page converters.</li>
<li><em>IBMALLP2 (or IBMPLPA1 for Enterprise PL/I for z/OS)</em>: This is a sample of
all Language Environment PL/I
component modules eligible for the LPA.</li>
<li><em>IGZWMLP4</em>: This is a sample of all Language Environment COBOL
component modules eligible for the LPA.</li></ul>
<p>To see which modules are eligible for the LPA, refer to <cite>z/OS Language Environment Customization</cite>.
The modules listed there can be put in the LPA or extended LPA (ELPA)
depending on their RMODE value:

</p>
<ul>
<li>If the RMODE is ANY, the module can reside in the LPA or in the
ELPA (above or below the 16 MB line).</li>
<li>If the RMODE is 24, the module can reside only in the LPA (below
the 16 MB line).</li></ul>
<p>If you are considering placing the modules listed in <cite>z/OS Language Environment Customization</cite> in
the LPA or the ELPA, then IBM recommends
that you place the SCEELPA data set in the LPA list (LPALST<span class="synph"><span class="var">xx</span></span>).
SCEELPA contains Language
Environment load modules that are reentrant, that reside above
the 16 MB line, and that are heavily used by z/OS.</p>
<p>In <cite>z/OS Language Environment Customization</cite> you
will also see tables of modules eligible for the LPA and the ELPA
above and beyond what is found in the SCEELPA data set. You will need
to use the dynamic LPA or MLPA approach to move these modules into
the LPA or ELPA. You do not need to include recommended modules if
they contain functions your installation does not use. Language Environment modules
not listed in these tables can be moved into the LPA or ELPA at your
discretion.</p>
<p><strong>Reference information</strong>: See the table &quot;Language Environment sample
IEALPAnn or PROGxx members in <span class="synph"><span class="var">hlq</span></span>.SCEESAMP&quot; for the list
of sample members and their changed content in <cite>z/OS Language Environment Customization</cite>.
The table contains a list of eligible load modules for:

</p>
<ul>
<li>Language Environment base
modules</li>
<li>Language Environment XL
C/C++ component modules</li>
<li>Language Environment COBOL
component modules</li>
<li>Language Environment Fortran
component modules</li>
<li>Language Environment PL/1
component modules</li></ul>
<h4 id="regionjcl">Determine if the region-level runtime option JCL requires changes</h4>
<p>[[[[ Contributing writer:Barbara A Neumann/Poughkeepsie/IBM@IBMUS
 ]]]] [[[[ Technical contact: John Monti/Poughkeepsie/IBM@IBMUS  ]]]]</p>
<p><strong>Description</strong>: Because of the changes introduced in <a href="e0z3m100.htm#ceeprmxx">Migrate to the CEEPRMxx parmlib support</a>, new region-level assembler
samples are provided in the SCEESAMP data set. These samples are called
CEERDOPT, CEERCOPT and CELQRDOP. Each sample contains the IBM-supplied
default values for runtime options.  The instructions in the CEEWROPT
and CEEWQROP sample JCL parts for creating region-level runtime options
load modules have been updated to refer to the new assembler samples. <a id="idx1152"></a><a id="idx1153"></a><a id="idx1154"></a></p>
<table id="wq597" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Language Environment.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if you need to create a
new region-level runtime options module.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: No action is needed for existing CEEROPT
modules or for JCL job which already contain a copy of the old assembler
samples. If you need to create a new region-level runtime options
module, use the updated JCL and sample assembler parts.</p>
<p><strong>Reference information</strong>: For more information about creating
region-level runtime option load modules, see <cite>z/OS Language Environment Customization</cite>.</p>
<h4 id="e0z3m100-gen55">Accommodate removals associated with setting the system-level
default runtime option in assembler modules</h4>
<p>[[[[ Contributing writer: Barbara A Neumann/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: John Monti/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: The Language Environment options reports,
which may be obtained by specifying RPTOPTS(ON), with the CLER CICS
transaction, with a CEEDUMP or using VERBX LEDATA in an IPCS readable
dump, will no longer show &quot;Installation Default&quot; as the last where
set field. If the runtime option defaults shipped with Language Environment
have not been changed, the last where set field will show &quot;IBM-supplied
default&quot;. Also, the last where set value of "Installation non-overrideable"
is no longer used.<a id="idx1155"></a><a id="idx1156"></a></p>
<table id="wq598" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Language Environment.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have an application that reads the
output of an options report.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  If you have programs that attempt to read
the output from these reports, your programs should be updated accordingly.
Similarly, if you were outputting an options report you should use
&quot;IBM-supplied default&quot; for a where set value that formerly matched
&quot;Installation default&quot;.</p>
<p><strong>Reference information</strong>: For more information, see: 
</p>
<ul>
<li><cite>z/OS Language Environment Debugging Guide</cite></li>
<li><cite>z/OS Language Environment Customization</cite></li>
<li><cite>z/OS Language Environment Programming Guide</cite></li>
<li><cite>z/OS Language Environment Programming Guide for 64-bit Virtual Addressing Mode</cite>.</li></ul>
<h4 id="ceeprmset">Convert to CEEPRMxx to set system-level default runtime options</h4>
<p>[[[[ Technical contact: John Monti/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: In the IBM z/OS V1.12 Software Announcement
210-235 dated 22 July 2010, IBM announced plans to remove, in a future
release, the capability to change the default Language Environment
runtime options settings using SMP/E installable USERMODs.  If you
are still using assembler modules to specify your installation-wide
default runtime options (CEEDOPT, CEECOPT, or CELQDOPT), IBM recommends
that you convert to using the CEEPRM<span class="synph"><span class="var">xx</span></span> parmlib
member to set your system-level default Language Environment runtime
options. z/OS V1R13 is planned to be the last release to support the
SMP/E USERMOD to customize the LE Run-time options.<a id="idx1157"></a><a id="idx1158"></a><a id="idx1159"></a></p>
<table id="wq599" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Language Environment.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1. (Previewed in IBM z/OS V1.12 Software
Announcement 210-235, 22 July 2010.)</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td> No, but recommended because even though the
runtime option usermods continue to be supported in this release,
IBM plans to remove this functionality in a future release of z/OS.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>Use CEE_USING_LE_PARMLIB to check that default
Language Environment runtime options are set within a CEEPRM<span class="synph"><span class="var">xx</span></span> parmlib
member.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:  
</p>
<ul>
<li>If you are no longer using the Language Environment runtime option
assembler usermods, you have no further action.</li>
<li>If you are using the Language Environment runtime option assembler
usermods, you should now convert to CEEPRM<span class="synph"><span class="var">xx</span></span> parmlib
member. Taking this step now will eliminate a migration action in
a future release.</li></ul>
<p><strong>Reference information</strong>: For details about specifying the
CEEPRM<span class="synph"><span class="var">xx</span> parmlib member</span>, see <cite>z/OS Language Environment Customization</cite>.</p>
<h4 id="ceeprmxx">Migrate to the CEEPRMxx parmlib support</h4>
<p>[[[[ Contributing writer: Barbara A Neumann/Poughkeepsie/IBM@IBMUS]]]]
[[[[ Technical contact: John Monti/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>:In z/OS V1R12, Language Environment issued a
statement of direction indicating that the preferred method of setting
default system-level runtime options is using the CEEPRMxx support.
The statement of direction further indicated that the ability to change
installation-level runtime options with SMP/E installable usermods
would be removed in a future release. Starting in z/OS V2R1, that
ability is removed. See <a href="e0z3m100.htm#ceeprmset">Convert to CEEPRMxx to set system-level default runtime options</a><a id="idx1160"></a></p>
<p>The CEEWDOPT, CEEWCOPT, and CEEWQDOP sample JCL jobs that were
used to install Language Environment runtime option usermods are no
longer included in the SCEESAMP dataset. The corresponding CEEDOPT,
CEECOPT, and CELQDOPT assembler source code samples, which contained
the IBM-supplied runtime option, are also no longer included in the
SCEESAMP dataset. Additionally, the CEEXOPT macro has been updated
to issue an MNOTE if the generation of a CEEDOPT or CELQDOPT CSECT
is requested.</p>
<table id="wq600" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Language Environment.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you still use the assembler language
usermods to modify installation-wide runtime options.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If you have not yet migrated to the simplified
method of using a CEEPRMxx parmlib member, which was available starting
at z/OS V1R7, you must do so now.</p>
<p><strong>Reference information</strong>: For more information about setting
system-level default runtime options, see <cite>z/OS Language Environment Customization</cite>.</p>
<h3 id="e0z3m100-gen128">Language
Environment actions to perform after the first IPL of z/OS V2R1</h3>
<p>This topic describes Language
Environment migration actions that you can perform only after
you have IPLed z/OS V2R1. You
need a running z/OS V2R1 system
to perform these actions.</p>
<p>None.<a id="idx1161"></a><a id="idx1162"></a><a id="idx1163"></a><a id="idx1164"></a><a id="idx1165"></a><a id="idx1166"></a></p>
<h2 id="ab1bser1">Library Server migration actions</h2>
<p>This topic describes migration actions for base element Library
Server.</p>
<p class="dtm2iddcomments">REVIEWERS: THERE WILL BE NEW MIGRATION
ACTIONS ADDED FOR THE NEXT REVIEW.</p>
<h3 id="e0z3m100-gen129">Library Server actions to perform before installing z/OS V2R1</h3><a id="idx1167"></a>
<p>This topic describes Library Server migration actions that you
can perform on your current (old) system. You do not need the z/OS
V2R1 level of code to make these changes, and the changes do not require
the z/OS V2R1 level of code to run once they are made.</p>
<p>None.</p>
<h3 id="libsb1i1">Library Server actions to perform before the first IPL of z/OS
V2R1</h3>
<p>This topic describes Library Server migration actions that you
can perform after you have installed z/OS V2R1
but before the first time you IPL. These actions might require the z/OS V2R1 level of code to be installed
but do not require it to be active.</p>
<p><a href="e0z3m100.htm#ab3conf1">Copy Library Server configuration files</a></p>
<p><a href="e0z3m100.htm#ab3note1">Copy Library Server notes files</a></p>
<h4 id="ab3conf1">Copy Library Server configuration files</h4><a id="idx1168"></a><a id="idx1169"></a><a id="idx1170"></a><a id="idx1171"></a><a id="idx1172"></a><a id="idx1173"></a>
<p><strong>Description</strong>: The Library Server configuration
files (<samp class="xph">bookmgr.80</samp>, <samp class="xph">booksrv.80</samp>) contain information
about your environment and preferences. The information in <samp class="xph">bookmgr.80</samp> includes
the names of bookshelf lists for bookshelves in MVS data sets and the names of the HFS directories
that Library Server reads and writes during execution. The information
in <samp class="xph">booksrv.80</samp> includes the HFS directory names of book
collections, shelves, and bookcases. There are default values but
normally you would customize them. In order to bring the customized
values over to your new system, you have to copy them. (Note that
port number suffix .80, used in <samp class="xph">bookmgr.80</samp> and <samp class="xph">booksrv.80</samp>,
is an example. Your port number suffix might be different.)</p>
<table id="wq601" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Library Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you intend to preserve your Library
Server configuration.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Copy your current (customized)
configuration files, usually <samp class="xph">bookmgr.80</samp> and <samp class="xph">booksrv.80</samp>,
to your new system and add any configuration parameters that are
new since the z/OS release
from which you are migrating. Otherwise Library Server will run
with default values, not the values you're used to. A suggested (but
not required) place for these configuration files is <samp class="xph">/etc/booksrv</samp>.
Library Server will also search <samp class="xph">/etc</samp> and the original cgi-bin
for them. If you place the files in any other directory, use the EPHConfigPath
environment variable to tell Library Server where to find them.</p>
<p><strong>Reference information</strong>: For a complete description
of each parameter of the Library Server configuration files, see <cite>z/OS Program Directory</cite>.</p>
<h4 id="ab3note1">Copy Library Server notes files</h4>
<p><strong>Description</strong>: Users can make comments in book
topics by creating notes that are appended to the end of each topic. <a id="idx1174"></a>
If you do not copy
these notes to the new system, they will be lost.</p>
<table id="wq602" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Library Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you intend to preserve notes from release
to release.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Copy all the files from your
existing notes directory to the new one. The default directory for
saving book notes is <samp class="xph">/usr/lpp/booksrv/public/bookmgr/notes</samp>.
You can override this default by specifying a directory on the NOTEDIR
parameter of the <samp class="xph">bookmgr.80</samp> configuration file.</p>
<p><strong>Reference information</strong>: For a complete description
of each parameter of the Library Server configuration files, see <cite>z/OS Program Directory</cite>.</p>
<h3 id="e0z3m100-gen130">Library Server actions to perform after the first IPL of z/OS
V2R1</h3>
<p>This topic describes Library Server migration actions that you
can perform only after you have IPLed z/OS V2R1.
You need a running z/OS V2R1
system to perform these actions.</p>
<p><a href="e0z3m100.htm#dt2mg434">Reconfigure Library Server InfoCenters</a></p>
<h4 id="dt2mg744">Reconfigure Library Server InfoCenters</h4><a id="idx1175"></a>
<p></p>
<p><strong>Description</strong>: Starting with z/OS V2R1, the Library Server
element requires the Location value (ICPATH=) value of InfoCenters
to be configured differently than it was in the past.  Thus, for any
existing InfoCenter configurations migrated from the previous version,
you must delete, reconfigure, re-index, and re-catalog the configurations
as described in <strong>Steps to take</strong>.  Also, if you want to configure
the z/OS MF InfoCenter (which is packaged with Library Server starting
with z/OS V2R1), you must also configure and catalog it. See the last
two steps in <strong>Steps to take</strong>.</p>
<table id="wq603" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Library
Server</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>after
the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you intend to preserve configured InfoCenters from the previous
version or configure the pre-packaged z/OS MF InfoCenter.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<ol type="1">
<li>Migrate your current customized booksrv.80 as described in <strong>Description</strong>.</li>
<li>Configure and start you HTTP server as required for Library Server
as described in the <cite>z/OS Program Directory</cite>.</li>
<li>Using the Library Server Administrative Interface, delete any
existing InfoCenter configuration entries.</li>
<li>Using the Library Server Administrative Interface, reconfigure
(that is,"create new") each deleted InfoCenter, using for its <em>Location</em>field
the fully qualified "root plugin" directory name, or jar file name,
of the InfoCenter. (Note that the "root plugin" is a child of the
InfoCenter parent directory and is typically distinguishable as the
plugin that contains the "plugin_customization.ini" file for the InfoCenter.)</li>
<li>Using the Library Server Administrative Interface, re-index all
the reconfigured InfoCenters.</li>
<li>If you want to configure the z/OS MF Infocenter that is packaged
with Library Server, use the Library Server Administrative Interface
to configure it.  Specify the ID (<strong>ICIDS=</strong>), Title (<strong>INFOCENTERS= </strong>),
and Location (<strong>ICPATH=</strong>) keyword values from the installed /usr/lpp/booksrv/cgi-bin/booksrv.conf
file. (Because it is already indexed before packaging, you do not
need to re-index the z/OS MF InfoCenter.)</li>
<li>Using the Library Server Administrative Interface, rebuild the
Library Server Catalog to copy/catalog all the InfoCenter objects
(for example, TOC files, plugin card files, and any extracted PDFs)
introduced by any of the previous steps.</li></ol>
<p><strong>Reference information:</strong>  For a complete description of each
parameter of the Library Server configuration files, see the <cite>z/OS
Program Directory</cite>.</p>
<h2 id="ao1rmf1">RMF migration actions</h2>
<p>This topic describes migration actions for optional feature Resource Measurement
Facility (RMF).</p>
<h3 id="e0z3m100-gen131">RMF actions to perform
before installing z/OS V2R1</h3><a id="idx1176"></a>
<p>This topic describes RMF migration actions that you can perform
on your current (old) system. You do not need the z/OS V2R1 level
of code to make these changes, and the changes do not require the
z/OS V2R1 level of code to run once they are made.</p>
<p>None.</p>
<h3 id="e0z3m100-gen132">RMF actions to perform
before the first IPL of z/OS V2R1</h3>
<p>This topic describes RMF migration actions that you can perform
after you have installed z/OS V1R13 but before the first time you
IPL. These actions might require the z/OS V1R13 level of code to be
installed but do not require it to be active.</p>
<p><a href="e0z3m100.htm#rmfexit1">Control the invocation of data reduction exit routines</a></p>
<p><a href="e0z3m100.htm#dt2mg442">Check your GPMSERVE and GPM4CIM options for TCP/IP address
regular expressions</a></p>
<p><a href="e0z3m100.htm#dt2mg444">Define the RACF definitions to enable the GPMSERVE Started
Task for Authorization Code zero (AC=0)</a></p>
<p><a href="e0z3m100.htm#msgerb81">Check your automation for Monitor III messages ERB812I and
ERB813I</a></p>
<h4 id="dt2mg747">Control the invocation of data reduction exit routines</h4><a id="idx1177"></a><a id="idx1178"></a><a id="idx1179"></a><a id="idx1180"></a><a id="idx1181"></a><a id="idx1182"></a>
<p><strong>Description</strong>: Before z/OS V2R1, you could not allow unauthorized
applications to take advantage of data reduction exit routines. As
of z/OS V2R1, if you are running unauthorized applications that invoke
the RMF Monitor II Sysplex Data Gathering service (ERB2XDGS) or the
RMF Monitor III Sysplex Data Retrieval service (ERB3XDRS), you can
take certain actions to allow the applications to make use of data
reduction exit routines.</p>
<table id="wq605" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx1183"></a><a id="idx1184"></a><a id="idx1185"></a><a id="idx1186"></a><strong>Element or
feature</strong>:</td>
<td>RMF.</td>
</tr>
<tr id="rmfexit1__d5">
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1. This function is rolled back to z/OS
V1R11 with APAR OA38022 for RMF Monitor II service and APAR OA37965
for RMF Monitor III.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12 without the PTFs for
APARs OA38022 and OA37965 applied.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have unauthorized applications that
invoke ERB2XDGS (RMF Monitor II Sysplex Data Gathering service) or
ERB3XDRS (RMF Monitor III Sysplex Data Retrieval service).</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: To allow your applications to make use of
data reduction exit routines specified with the ERB2XDGS or ERB3XDRS
services, take the following actions:</p>
<ul>
<li>If the application has been designed to run authorized, you must
adapt the application or program so that it runs in supervisor state,
system state, or be APF authorized.</li>
<li>You can approve the exit by adding RACF resource ERBSDS.MON2EXIT.&lt;<span class="synph"><span class="kwd">exit_name</span></span>&gt;
or ERBSDS.MON3EXIT.&lt;<span class="synph"><span class="kwd">exit_name</span></span>&gt; to
the RACLISTed class FACILITY and by granting read access to the profile
for the user ID that invokesg the Sysplex Data Server API.</li>
<li>If you are running an unauthorized application that invokes RMF
Monitor II Sysplex Data Gathering service ERB2XDGS/ERB2XD64 or Monitor
III Sysplex Data Retrieval service ERB3XDRS/ERB3XD64, you must take
one of the following actions to allow the application to make use
of data reduction exits.


<ol type="1">
<li>If the application is properly designed and secure to run authorized,
you must adapt the application or program so that it runs in supervisor
state, system state, or APF authorized.</li>
<li> You can approve the exit by adding RACF resource ERBSDS.MON2EXIT &lt;<span class="synph"><span class="kwd">exit_name</span></span>&gt;
or ERBSDS.MON3EXIT&lt;<span class="synph"><span class="kwd">exit_name</span></span>&gt;.RACLISTed
class FACILITY and by granting read access to the profile for the
user id invoking the Sysplex Data Server API.</li></ol></li></ul>
<p><strong>Reference information</strong>: For details about the RMF sysplex
data services see <cite>z/OS RMF Programmer's Guide</cite>.</p>
<h4 id="dt2mg748">Check your GPMSERVE and GPM4CIM options for TCP/IP address
regular expressions</h4><a id="idx1187"></a>
<p>[[[Juergen
Kuhn/Germany/IBM@IBMDE]]]</p>
<p><strong>Description</strong>: Starting with z/OS V2R1, the RMF GPMSERVE Started
Task runs as a module linked with Authorization Code zero  (AC=0).
The following two actions are required with regard to RACF. 
</p>
<ol type="1">
<li>Define READ access to the BPX.SERVER FACILITY class for the GPMSERVE
userid.</li>
<li>Ensure that all programs loaded by GPMSERVE are defined to PROGRAM
CONTROL.</li></ol>
<table id="wq608" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>RMF</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes,
if you use GPMSERVE or GPM4CIM with IPv6 address regular expressions.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If you use GPMSERVE or GPM4CIM in an IPv6
or dual mode IPv6/IPv4 network environment, check one or more of your
options parmlib members for options containing regular expressions
representing IP addresses (for example, the options HTTP_ALLOW or
HTTP_NOAUTH). Make sure that the regular expressions adhere strictly
to the format of the IP addresses in your network. Examples include
the following:
</p>
<table id="wq609" width="100%" summary="" border="1" frame="border" rules="all">
<caption><a href="e0z3m100.htm#FT_Table_15">Table 15. Examples of IP matches</a></caption>
<thead valign="bottom">
<tr valign="bottom">
<th id="wq610" width="14%" align="left">IP address expression</th>
<th id="wq611" width="31%" align="left">Match</th>
<th id="wq612" width="53%" align="left">Examples of full IP address match</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq610">'6.*'</td>
<td headers="wq611">Matches any IP address starting with '6.'</td>
<td headers="wq612">6.19.107.32' or '6.34.88.103'</td>
</tr>
<tr>
<td headers="wq610">'::ffff:6.*'</td>
<td headers="wq611">Matches any (mapped) IP address starting with
'::ffff:6.'</td>
<td headers="wq612">'::ffff:6.19.107.32' or '::ffff:6.9.50.7'</td>
</tr>
<tr>
<td headers="wq610">'*6.*'</td>
<td headers="wq611">Matches any IP address containing a substring
'6.'</td>
<td headers="wq612">'::ffff:6.9.50.7' or '6.19.107.32'</td>
</tr>
</tbody>
</table>
<p><strong>Reference information</strong>For
further information see <span id="dt2mg749">z/OS RMF User's Guide</span>:</p>
<h4 id="dt2mg750">Define the RACF definitions to enable the GPMSERVE Started
Task for Authorization Code zero (AC=0)</h4><a id="idx1188"></a>
<p></p>
<p>
<h5 id="wq613">Description:</h5><a id="idx1189"></a></p>
<p>
<p>Starting with z/OS V2R1, the RMF GPMSERVE Started Task runs
as a module linked with Authorization Code zero  (AC=0).</p>
<p>The following
two actions are required with regard to RACF.
</p>
<ol type="1">
<li>Define READ access to the BPX.SERVER FACILITY class for the GPMSERVE
userid</li>
<li>Ensure that all programs loaded by GPMSERVE are defined to PROGRAM
CONTROL</li></ol></p>
<table id="wq616" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>RMF</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p>
<h5 id="wq617">Steps to take:</h5></p>
<ol type="1">
<li>Define READ Access to the BPX.SERVER Facility for the GPMSERVE
userid: 
<pre class="xmp"><code>PERMIT BPX.DAEMON CLASS(FACILITY) ID(GPMSERVE) ACCESS(READ)</code></pre></li>
<li>Ensure that all programs loaded by GPMSERVE are defined to PROGRAM
CONTROL:    
<pre class="xmp"><code>RDEFINE PROGRAM GPM* ADDMEM(&rsquo;SYS1.SERBLINK&rsquo;//NOPADCHK) UACC(READ)
RDEFINE PROGRAM ERB* ADDMEM(&rsquo;SYS1.SERBLINK&rsquo;//NOPADCHK) UACC(READ)
RDEFINE PROGRAM CEEBINIT ADDMEM(&rsquo;CEE.SCEERUN&rsquo;//NOPADCHK) UACC(READ)
RDEFINE PROGRAM IEEMB878 ADDMEM(&rsquo;SYS1.LINKLIB&rsquo;//NOPADCHK) UACC(READ)
RDEFINE PROGRAM CELHV003 ADDMEM(&rsquo;SYS1.SCEERUN2&rsquo;//NOPADCHK) UACC(READ)
RDEFINE PROGRAM C128 ADDMEM(&rsquo;SYS1.SCEERUN2&rsquo;//NOPADCHK) UACC(READ)
RDEFINE PROGRAM CELHDCPP ADDMEM(&rsquo;SYS1.SCEERUN2&rsquo;//NOPADCHK) UACC(READ)
SETROPTS WHEN(PROGRAM) REFRESHs</code></pre> This action is only needed
when GPMSERVE is not already defined to PROGRAM CONTROL. In previous
RMF Releases this was recommended  but not required since the GPMSERVE
module was linked with Authorization Code one (AC=1).</li></ol>
<p>
<h5 id="wq619">Reference information:</h5>
<p>For
further information see <em>z/OS RMF User's Guide.</em></p></p>
<h4 id="msgerb81">Check your automation for Monitor III messages ERB812I and
ERB813I</h4>
<p>[[[[ Contributing writer: Stephan Hartig/Germany/IBM@IBMDE
]]]] [[[[ Technical contact: Peter Muench/Germany/IBM@IBMDE ]]]]</p>
<p><strong>Description</strong>: Starting with z/OS V1R13, RMF Monitor III messages
ERB812I and ERB813I are issued as single line WTO messages. Before
z/OS V1R13, for those messages, there could have been multiple WTOs
if the message length was longer than 69 characters. If you use an
automation product that processes these messages, check the algorithm,
and, if required, adapt it to the new message output. <a id="idx1190"></a><a id="idx1191"></a></p>
<table id="wq620" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>RMF.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use automation products for RMF
messages ERB812I and ERB813I.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If you use an automation product that processes
RMF Monitor III messages ERB812I and ERB813I, check the algorithm
because the output format of these messages changes in z/OS V1R13
RMF.</p>
<p>Below are examples of the old output format and the new output
format for these messages. Check the code of your automation product
to determine if you need to adapt it to the new message output format.</p>
<p><strong><span class="bold-italic">Old output format</span></strong>:&nbsp;</p>
<pre class="xmp"><code>ERB812I III: MONITOR III DATA RECORDING INTO DATA SET 'RMF.MONITOR3.D
ERB812I III:     ATASET3.SYSE' STOPPED
ERB813I III: ACTIVE MONITOR III DATA SET IS NOW 'RMF.MONITOR3.DATASET
ERB813I III:     4.SYSE'</code></pre>
<p><strong><span class="bold-italic">New output format</span></strong>:&nbsp;</p>
<pre class="xmp"><code>ERB812I III: MONITOR III DATA RECORDING INTO DATA SET 'RMF.MONITOR3.DATASET3.SYSE' STOPPED
ERB813I III: ACTIVE MONITOR III DATA SET IS NOW 'RMF.MONITOR3.DATASET4.SYSE'</code></pre>
<p><strong>Reference information</strong>: For further information see <cite>z/OS RMF Messages and Codes</cite>.</p>
<h3 id="e0z3m100-gen133">RMF actions to perform
after the first IPL of z/OS V2R1</h3>
<p>This topic describes RMF migration
actions that you can perform only after you have IPLed z/OS V2R1. You need a running z/OS V2R1 system to perform these actions.</p>
<p><a href="e0z3m100.htm#rmflater1">Use an RMF Monitor III
reporter version equal to or later than your RMF Monitor III gatherer version</a></p>
<p><a href="e0z3m100.htm#rmfzfs1">Monitor the zFS file system activity</a></p>
<p><a href="e0z3m100.htm#psdrept">Determine need of SMF data collection for Postprocessor
PCIE Activity report based on SMF 74.9 record.</a></p>
<p><a href="e0z3m100.htm#dt2mg755">Determine need of SMF data collection for Postprocessor
Serialization Delay report</a></p>
<h4 id="rmflater1">Use an RMF Monitor III
reporter version equal to or later than your RMF Monitor III gatherer version</h4><a id="idx1192"></a><a id="idx1193"></a><a id="idx1194"></a><a id="idx1195"></a><a id="idx1196"></a><a id="idx1197"></a>
<p>[[[[ Contributing writer: Stephan Hartig/Germany/IBM@IBMDE
]]]] [[[[ Technical contact: Peter Muench]]]]</p>
<p><strong>Description</strong>: To avoid problems when reporting Monitor III
data, use an RMF reporter version
that is equal to or later than the latest RMF gatherer
version used to collect the data to be reported. For example, it is
safe to use an RMF reporter version
from z/OS V1R13 for data collected
with an RMF gatherer from z/OS V1R12, but not vice versa.
 <a id="idx1198"></a></p>
<p>Mixed (and therefore problematic) levels of collected data can
occur in the following scenarios:  
</p>
<ul>
<li><em>Single system</em>: You install and test a new release, then
fall back to an earlier one; your data sets might contain data collected
with different versions of the RMF gatherer.</li>
<li><em>Sysplex</em>: You migrate to a new release on one system in
a sysplex but try to use an earlier reporter version from another
system to report on the migrated system's data.</li></ul>
<table id="wq621" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>RMF.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1/R13
and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you had planned to use an earlier-level RMF reporter on data that was collected
with a later-level RMF gatherer.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>See &quot;Steps to take&quot; below.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Always use an RMF Monitor
III reporter version that is equal to or later than the gatherer version
used to collect the data from which you want to produce a report.</p>
<div>
<div class="note-noindent" id="wq622">
<span class="notetitle">Note:</span> <span class="notebody">Monitor III notifies users by issuing information message ERB948I
when a reporter session is started on a system in a sysplex that is
not running with the highest RMF level
available in the sysplex. The message helps users to avoid reporting
problems.</span></div></div>
<p><strong>Reference information</strong>: For more information about Monitor
III commands, see <cite>z/OS RMF User's Guide</cite>.</p>
<h4 id="dt2mg753">Monitor the zFS file system activity</h4>
<p><strong>Description</strong>: Before z/OS V2R1, the RMF Monitor III data
gatherer ERBRMF04 parmlib options ZFS and NOZFS controlled the data
collection for measuring zFS file system activity, the default was
to activate the data collection. As of V2R1, RMF no longer automatically
gathers any data about zFS file system activity.</p>
<table id="wq623" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx1199"></a><a id="idx1200"></a><a id="idx1201"></a><strong>Element or feature</strong>:</td>
<td>RMF.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to collect data about zFS file
system activity.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Determine if you want to monitor zFS file
system activity. When starting a Monitor III session in this case,
you can permanently specify the ZFS option in the parmlib member for
your Monitor III data gatherer sessions. Or you can use the following
RMF MODIFY command during a running session:  </p>
<pre class="xmp"><code>MODIFY RMF,MODIFY III,ZFS</code></pre>
<p><strong>Reference information</strong>: For details about zFS file system
data gathering see <cite>z/OS RMF User's Guide</cite>.</p>
<h4 id="dt2mg754">Determine need of SMF data collection for Postprocessor
PCIE Activity report based on SMF 74.9 record.</h4>
<p>[[[[ Contributing writer: Stephan Hartig/Germany/IBM@IBMDE
]]]] [[[[ Technical contact: Regine Reichert/Germany/IBM@IBMDE ]]]]</p>
<p><strong>Description</strong>: Starting with z/OS V2R1, RMF provides a new
Postprocessor PCIE Activity report based on SMF 74.9 record. If you
do not need this report, <span>you should turn off data collection
for SMF record 74 subtype 9.</span><a id="idx1202"></a><a id="idx1203"></a></p>
<table id="wq624" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>RMF.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if you do not want to collect
SMF data for the Postprocessor PCIE Activity report.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Determine if you want to use the new Postprocessor
PCIE Activity report. SMF data required for this report is gathered
by default. If you do not want to use this report, you should suppress
the SMF data collection for the new record type 74 subtype 9. You
achieve this by specifying NOTYPE for this SMF record type in the
SMF parmlib member SMFPRM<span class="synph"><span class="var">xx</span></span>.</p>
<p>Another method to suppress the data gathering of record
74.9 for the Postprocessor PCIE Activity report is to use the SUBSYS
parameter in the SMFPRM<span class="synph"><span class="var">xx</span></span> parmlib member
for the STC subsystem (started tasks, where RMF is one of them). To
exclude data gathering for SMF record 74.9, specify <span class="synph"><span class="kwd">SUBSYS(STC,NOTYPE(74(9)),
... )</span></span>.</p>
<p>The SUBSYS specification overrides the SYS specification.
So for example, if you have defined <span class="synph"><span class="kwd">SYS(TYPE(...,74,...))</span></span> in
your SMFPRM<span class="synph"><span class="var">xx</span></span> parmlib member, you can use <span class="synph"><span class="kwd">SUBSYS(STC,
NOTYPE(74(9)))</span></span> to make exceptions to your SYS specification
and just exclude gathering of SMF record 72.5 for started tasks like
RMF.</p>
<p><strong>Reference information</strong>: For details about specifying SMF
data collection, see <cite>z/OS MVS Initialization and Tuning Reference</cite>.</p>
<h4 id="dt2mg755">Determine need of SMF data collection for Postprocessor
Serialization Delay report</h4>
<p>[[[[ Contributing writer: Stephan Hartig/Germany/IBM@IBMDE
]]]] [[[[ Technical contact: Regine Reichert/Germany/IBM@IBMDE ]]]]</p>
<p><strong>Description</strong>: Starting with z/OS V1R13, RMF provides a new
Postprocessor Serialization Delay report. If you do not need this
report, <span>you should turn off data collection for SMF record
72 subtype 5.</span><a id="idx1204"></a><a id="idx1205"></a></p>
<table id="wq625" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>RMF.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if you do not want to collect
SMF data for the Postprocessor Serialization Delay report.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Determine if you want to use the new Postprocessor
Serialization Delay report. SMF data required for this report is gathered
by default. If you do not want to use this report, you should suppress
the SMF data collection for the new record type 72 subtype 5. You
achieve this by specifying NOTYPE for this SMF record type in the
SMF parmlib member SMFPRM<span class="synph"><span class="var">xx</span></span>.</p>
<p>Another method to suppress the data gathering of record
72.5 for the Serialization Delay report is to use the SUBSYS parameter
in the SMFPRM<span class="synph"><span class="var">xx</span></span> parmlib member for the STC
subsystem (started tasks, where RMF is one of them). To exclude data
gathering for SMF record 72.5, specify <span class="synph"><span class="kwd">SUBSYS(STC,NOTYPE(72(5)),
... )</span></span>.</p>
<p>The SUBSYS specification overrides the SYS specification.
So for example, if you have defined <span class="synph"><span class="kwd">SYS(TYPE(...,72,...))</span></span> in
your SMFPRM<span class="synph"><span class="var">xx</span></span> parmlib member, you can use <span class="synph"><span class="kwd">SUBSYS(STC,
NOTYPE(72(5)))</span></span> to make exceptions to your SYS specification
and just exclude gathering of SMF record 72.5 for started tasks like
RMF.</p>
<p><strong>Reference information</strong>: For details about specifying SMF
data collection, see <cite>z/OS MVS Initialization and Tuning Reference</cite>.</p>
<h2 id="ap1sdsf1">SDSF migration actions</h2>
<p>This topic describes migration actions for optional feature SDSF.</p>
<h3 id="e0z3m100-gen134">SDSF actions to perform before installing z/OS V2R1</h3><a id="idx1206"></a>
<p>This topic describes SDSF migration actions that you can perform
on your current (old) system. You do not need the z/OS V2R1 level
of code to make these changes, and the changes do not require the
z/OS V2R1 level of code to run once they are made.</p>
<p>None.</p>
<h3 id="e0z3m100-gen135">SDSF actions to perform before the first IPL of z/OS V2R1</h3>
<p>This topic describes SDSF migration actions that you can perform
after you have installed z/OS V2R1
but before the first time you IPL. These actions might require the z/OS V2R1 level of code to be installed
but do not require it to be active.</p>
<p><a href="e0z3m100.htm#ax3exit1">Review and reassemble user exit routines</a></p>
<p><a href="e0z3m100.htm#ax3assm1">Use dynamic statements for ISFPARMS to avoid reassembly</a></p>
<h4 id="ax3exit1">Review and reassemble user exit routines</h4><a id="idx1207"></a><a id="idx1208"></a><a id="idx1209"></a><a id="idx1210"></a><a id="idx1211"></a><a id="idx1212"></a>
<p><strong>Description</strong>: If you have written user exit
routines, review them to ensure they are still appropriate for the
current environment, and make changes as necessary. <a id="idx1213"></a><a id="idx1214"></a>
All user exit
routines must be reassembled with the z/OS V1R13
level of the SDSF macro library.</p>
<table id="wq626" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>SDSF.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if user exit routines are in use.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Review user exit routines
to ensure they are appropriate for z/OS V1R13.
Make changes as necessary. Regardless of whether you have made changes,
reassemble the user exit routines with the z/OS V1R13 level of the SDSF macro library.</p>
<p>Tip: A PROPLIST statement, along with PROPERTY
statements, both in the ISFPRM<span class="synph"><span class="var">xx</span></span> parmlib member, defines
customized values for certain SDSF properties. It provides an alternative
to writing user exit routines to customize those properties. A user
exit routine that customizes the same property as a PROPERTY statement
overrides the value on the PROPERTY statement.</p>
<p><strong>Reference information</strong>: See <cite>z/OS SDSF Operation and Customization</cite>.</p>
<h4 id="ax3assm1">Use dynamic statements for ISFPARMS to avoid reassembly</h4>
<p><strong>Description</strong>: ISFPARMS in SDSF is used for specifying global
options, the format of panels, and security for SDSF functions.  SDSF
provides two alternatives for ISFPARMS: 
</p>
<ul>
<li>Assembler macros that you define, assemble, and then link into
the SDSF load library. This is the original format for defining ISFPARMS
and it continues to be supported for compatibility.</li>
<li>Dynamic statements, which are in parmlib member ISFPRM<span class="synph"><span class="var">xx</span></span>.
Dynamic statements are the recommended format. They are easier to
code and are more dynamic than the assembler macros; they can be updated
without reassembling or link-editing. The statements are processed
by an SDSF server, which is controlled by MVS operator
commands.</li></ul>
<table id="wq627" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><a id="idx1215"></a><strong>Element
or feature</strong>:</td>
<td>SDSF.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended to avoid the migration action
of reassembling your customized ISFPARMS for each z/OS release.  (If you do not use dynamic statements
for ISFPARMS, reassembly of your customized ISFPARMS is required on
each release.)</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>Use check SDSF_ISFPARMS_IN_USE to verify that
SDSF dynamic statements in ISFPRM<span class="synph"><span class="var">xx</span></span> are
being used rather than the assembler macros. If the check determines
that the assembler macro ISFPARMS is in use instead, and that it has
been modified, the check generates an exception. If the assembler
macro ISFPARMS is in use but it has not been modified, so that all
defaults are in effect, the check does not generate an exception. 

<p>SDSF
registers this check with the IBM Health
Checker for z/OS infrastructure
when the SDSF server address space is initialized. However, one of
the items this check verifies is that the SDSF server itself is in
use, so you have to manually add this check (particularly if you do
not use the SDSF server) so that the IBM Health
Checker for z/OS infrastructure
will invoke the check. To add the check, put the following statement
in your PROG<span class="synph"><span class="var">xx</span></span> parmlib member: <samp class="xph">EXIT
ADD EXITNAME(HZSADDCHECK) MODNAME(ISFHCADC)</samp>.</p> 

<p>SDSF
health checks are distributed in ISF.SISFLOAD for installations running
SDSF in the LNKLST. The checks are also distributed in ISF.SISFLINK
for installations that do not run SDSF in the LNKLST. For those installations,
ISF.SISFLINK must be added to the LNKLST.</p> 

<p> </p>
<div>
<div class="note-noindent" id="wq628">
<span class="notetitle">Note:</span> <span class="notebody"> To
avoid a possible ABEND 290 <span>with reason code 02014007</span> issued
by HZSADDCK:  

<ul>
<li>Make sure that you specify the proper check routine name. The
check routine module must be in an APF-authorized library. The system
must be able to locate the check routine within the joblib, the steplib
of the IBM Health Checker for z/OS address space, the LPA, or the
LNKLST.</li>
<li>Make sure that you specify the proper message table name. The
message table module must be in an APF-authorized library. The system
must be able to locate the message table within the joblib, the steplib
of the IBM Health Checker for z/OS address space, the LPA, or the
LNKLST.</li></ul></span></div></div></td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If you are already using dynamic statements
for ISFPARMS<span class="synph"><span class="var">xx</span></span>, there is no migration action
to perform.</p>
<p>If you are using assembler macros for ISFPARMS, do one of the following: 
</p>
<ul>
<li>Convert your existing ISFPARMS to dynamic statements by using
a conversion utility that you invoke with the ISFACP command.</li>
<li>Reassemble your customized ISFPARMS for use with z/OS V1R13.  Reassembly must be done whenever
you change your z/OS release.
Before reassembling ISFPARMS, you might want to update it for new
function. The assembler ISFPARMS cannot be shared with any other release
of SDSF. Only use ISFPARMS for the release on which it is assembled.
 
<div>
<div class="note-noindent" id="wq629">
<span class="notetitle">Note:</span> <span class="notebody">If you have an SMP/E usermod that specifies modifications
to assembler macro ISFPARMS, change the usermod to indicate that module
ISFPARMS is now owned by the z/OS V2R1 SDSF JES2 feature FMID (JJE779S)
and not the base z/OS V2R1 SDSF FMID (HQX7790). The correct SMP/E
syntax is ++VER(Z038) FMID(JJE779S), not ++VER(Z038) FMID(HQX7790).</span></div></div></li></ul>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li>For details about invoking the conversion utility with the ISFACP
command, see <cite>z/OS SDSF Operation and Customization</cite>.</li>
<li>For information about ISFPARMS and the ISFPRM<span class="synph"><span class="var">xx</span></span> parmlib
member, see "ISFPARMS format alternatives" in  <cite>z/OS SDSF Operation and Customization</cite>.</li></ul>
<h3 id="e0z3m100-gen136">SDSF actions to perform after the first IPL of z/OS V2R1</h3>
<p>This topic describes SDSF migration actions that you can perform
only after you have IPLed z/OS V1R13.
You need a running z/OS V1R13
system to perform these actions.</p>
<p><a href="e0z3m100.htm#dt2mg762">Control how SDSF handles MCS extended (EMCS) consoles</a></p>
<p><a href="e0z3m100.htm#wbmqsdsf">Update configuration for sysplex support</a></p>
<p><a href="e0z3m100.htm#operlgcol">Review colors on the OPERLOG panel</a></p>
<p><a href="e0z3m100.htm#pnchrdr">Set the format of device names on the Punch and Reader panels</a></p>
<h4 id="dt2mg762">Control how SDSF handles MCS extended (EMCS) consoles</h4><a id="idx1216"></a><a id="idx1217"></a><a id="idx1218"></a><a id="idx1219"></a><a id="idx1220"></a><a id="idx1221"></a>
<p>[[[[ Contributing writer: Bill Keller]]]]
[[[[ Technical contact: Ken Jonas]]]]</p>
<p><strong>Description</strong>: As of z/OS V2R1 the behavior for obtaining
an extended MCS (EMCS) console (used for issuing system commands)
has changed. Before z/OS V2R1, when SDSF attempted to obtain an EMCS
console and the default extended console name was already in use,
SDSF shared that console. For example, if you used ISPF split screen
and accessed SDSF in multiple logical screens, SDSF shared the console
activated in the first logical screen with subsequent logical screens.
As a result, the user log in the first logical screen contained system
messages for all of the logical screens.<a id="idx1222"></a><a id="idx1223"></a></p>
<p>With V2R1, when SDSF attempts to activate an EMCS console and the
default console name is in use, SDSF activates a new console with
a different name. The new name is derived by appending a single-character
suffix to the default name. SDSF tries up to 32 different characters
to create a unique console name.</p>
<p> If you want SDSF to share the EMCS console, rather than obtaining
a new console with a name derived by modifying the default console
name, you can disable console name modification. You can also define
which characters should be used for the suffix that modifies the default
console name.</p>
<table id="wq630" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>SDSF.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want SDSF to share the extended
console, as in previous releases.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>When you apply the PTF for SDSF APAR PM78102
in prior releases, you should be able to share the ISFPRMxx parmlib
member, which includes new custom property Console.EMCS.NoConMod and
Console.EMCS.ConModChars. The new properties are ignored on systems
earlierl than V2R1.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: To disable console name modification, so
that, as in previous releases, SDSF shares the extended console when
the default name is already in use, you can use: 
</p>
<ul>
<li>The SET CONMOD (ON|OFF) command</li>
<li>The custom property Console.EMCS.NoConMod in the ISFPRMxx parmlib
member</li>
<li>In a REXX exec, the ISFCONMOD special variable</li>
<li>In a Java program, ISFRequestSettings.</li></ul>
<p>To specify which characters can be used as a suffix to modify the
default EMCS console name, use custom property Console.EMCS.ConModChars
in the ISFPRMxx parmlib member. By default, the characters are $#@12345.</p>
<p><strong>Reference information</strong>: For details about setting custom
properties in ISFPARMS, see the discussion of the PROPLIST nad PROPERTY
statements in <cite>z/OS SDSF Operation and Customization</cite>.</p>
<h4 id="wbmqsdsf">Update configuration for sysplex support</h4>
<p>[[[[ Contributing writer: William Keller/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Ken Jonas/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><a id="idx1224"></a><a id="idx1225"></a><strong>Description</strong>: When SDSF originally
introduced support for sysplex-wide device and resource panels in
a JES2 environment, that support required WebSphere&reg; MQ, SDSF servers and a server
group defined in ISFPARMS. In recent releases, SDSF enhancements have
reduced the requirement for WebSphere MQ
and the server group. Beginning with z/OS V1R13, SDSF completely eliminates
the need for WebSphere MQ
and the server group when all systems are at the z/OS V1R13 level
or higher.</p>
<p>The following panels are made sysplex-wide by default: LI (lines),
NO (nodes), PUN (punches), RDR (readers) and SO (spool offloaders).</p>
<p>The following panels now use cross system coupling facility (XCF)
support to provide sysplex-wide data: CK (checks), ENC (enclaves),
PS (processes) and RM (JES2 resources). Using XCF for the sysplex-wide
data is preferable because XCF is always present and no configuration
is required.</p>
<p>If you have configured SDSF's sysplex support in previous releases,
you may now have obsolete WebSphere MQ
configuration and server group definitions in ISFPARMS.</p>
<p> For the CK, ENC, PS and RM panels, you may need to perform some
configuration to ensure that all of the systems are included in sysplex-wide
panels.</p>
<table id="wq631" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>SDSF.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If all of the systems in the sysplex are
at the z/OS V1R13 level: 
</p>
<ul>
<li>Consider removing obsolete definitions: 

<ul>
<li>Server group statements (SERVERGROUP, SERVER and COMM) in ISFPARMS.</li>
<li>WebSphere MQ configuration and related SAF profiles, including
queues that you defined for SDSF and SAF profiles that protect the
queues used by SDSF.</li></ul></li>
<li>Ensure that the names of the SDSF servers are the same on all
systems. By default, SDSF uses the SDSF server name for the XCF application
server name to obtain sysplex-wide data for the CK, ENC, PS and RM
panels. If the names of the servers are not the same on all systems,
you must specify the suffix of an XCF server name with the CONNECT
statement in ISFPARMS.</li></ul>
<p>If the sysplex includes systems at the z/OS V1R13 or z/OS
V2R1 level, and others at a lower level, and you want to include the
lower level systems on the CK, ENC, PS or RM panels, you must set
the communications mode to Z12. This causes SDSF to obtain sysplex-wide
data as in previous releases, using WebSphere MQ and the server group.
To set the communications mode: 
</p>
<ul>
<li>Users can issue this command: SET CMODE Z12.</li>
<li>System programmers can use this custom property in ISFPARMS: Comm.Release.Mode.
You set a custom property with the PROPLIST and PROPERTY statements <span>in ISFPRM<span class="synph"><span class="var">xx </span></span> parmlib member</span>.</li></ul>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li>For more information about the <span class="synph"><span class="kwd">SET CMODE</span></span> command,
refer to the online help. For more information about ISFPRM<span class="synph"><span class="var">xx</span></span>, WebSphere MQ configuration
and security and the requirements for sysplex-wide panels when the
sysplex has mixed levels of z/OS and JES2, refer to <cite>z/OS SDSF Operation and Customization, SA23-2274</cite>.</li>
<li>For information about ISFPARMS and the ISFPRM<span class="synph"><span class="var">xx</span></span> parmlib
member, see "ISFPARMS format alternatives" in  <cite>z/OS SDSF Operation and Customization</cite>.</li></ul>
<h4 id="operlgcol">Review colors on the OPERLOG panel</h4>
<p>[[[[ Contributing writer: William Keller/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Ken Jonas/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Starting with z/OS V1R13, messages are displayed
on the OPERLOG panel with the color that was assigned to them when
they were issued. Users can customize colors or disable the use of
color with the SET SCREEN command.<a id="idx1226"></a></p>
<table id="wq632" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>SDSF.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want to disable color on the OPERLOG
panel.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: To disable color on the OPERLOG panel, use
the <span class="synph"><span class="kwd">SET SCREEN</span></span> command.</p>
<p><strong>Reference information</strong>: For more information on the <span class="synph"><span class="kwd">SET
SCREEN</span></span> command, refer to the online help.</p>
<h4 id="pnchrdr">Set the format of device names on the Punch and Reader panels</h4>
<p>[[[[ Contributing writer: William Keller/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Ken Jonas/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Starting with z/OS V1R13, SDSF shows device
names on the Punch (PUN) and Reader (RDR) panels in a longer format,
with dots between subtypes. This could affect batch programs or REXX
execs that process the device names. The system programmer can use
a custom property to retain the shorter format that was used in previous
releases.<a id="idx1227"></a><a id="idx1228"></a><a id="idx1229"></a><a id="idx1230"></a></p>
<table id="wq633" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>SDSF.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want device names on the PUN and
RDR panels to be displayed in the shorter format, as in previous releases.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: In <span>ISFPRM<span class="synph"><span class="var">xx</span></span></span>,
set custom property Panel.PUN.DevNameAlwaysShort and Panel.RDR.DevNameAlwaysShort
to TRUE, to use the short form of devices names on the PUN and RDR
panels.</p>
<p><strong>Reference information</strong>: For details about setting the custom
property in <span>ISFPRM<span class="synph"><span class="var">xx</span></span></span>,
see the discussion of the PROPLIST nad PROPERTY statements, in <cite>z/OS SDSF Operation and Customization, SA23-2274</cite>.</p>
<h2 id="aq1secs1">Security Server migration actions</h2>
<p>This topic describes migration actions for optional feature Security
Server.</p>
<h3 id="e0z3m100-gen137">Security Server actions to perform before installing z/OS V2R1</h3><a id="idx1231"></a>
<p>This topic describes Security Server migration actions that you
can perform on your current (old) system. You do not need the z/OS V2R1 level of code to make
these changes, and the changes do not require the z/OS V2R1 level of code to run once they are
made.<a id="idx1232"></a><a id="idx1233"></a><a id="idx1234"></a><a id="idx1235"></a><a id="idx1236"></a></p>
<p><a href="e0z3m100.htm#omvs1"> Discontinue using the default OMVS segment support</a></p>
<p><a href="e0z3m100.htm#distname">Normalize user names specified as X.500 distinguished names
in distributed identity filters</a></p>
<h4 id="dt2mg764"> Discontinue using the default OMVS segment support</h4>
<p>[[[[ Marna Walle]]]]</p>
<p><strong>Description</strong>: IBM has strongly discouraged customers
from using default OMVS segments and instead recommends that all z/OS
UNIX users or groups have OMVS segments defined for user and group
profiles with unique UIDs and GIDs.  Use of RACF support for automatically
generating unique UIDs and GIDs on demand for users and groups that
do not have OMVS segments defined is the recommended alternative.
Support for automatic unique UID and GID generation has been available
since z/OS V1R11.</p>
<p>As of z/OS V2R1, the ability to use default OMVS segments
has been removed.</p>
<table id="wq634" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Security Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1. See RFA IBM United States Software
Announcement 211-007, dated February 15, 2011.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you are using the default OMVS segment
support.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>You need AIM Stage 3 to use the BPX.UNIQUE.USER
profile. You can run the IRRIRA00 utility to determine the current
AIM Stage in your RACF database.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>Use check ZOSMIGV2R1_DEFAULT_UNIX_ID introduced
in APAR OA37164. This check determines if you are relying on assigning
default z/OS UNIX identities for users without OMVS segments.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Follow the steps in <cite>z/OS UNIX System Services Planning</cite> to
set up the BPX.UNIQUE.USER profile. If BPX.DEFAULT.USER has not been
deleted, BPX.UNIQUE.USER takes precedence when default OMVS segments
are used.</p>
<p>To remove the BPX.DEFAULT.USER profile, use the following RACF commands: </p>
<pre class="xmp"><code>RDELETE FACILITY BPX.DEFAULT.USER 
SETROPTS RACLIST(FACILITY) REFRESH</code></pre>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li><cite>z/OS UNIX System Services Planning</cite></li>
<li><cite>z/OS Security Server RACF Security Administrator&amp;apos;s Guide</cite></li></ul>
<h4 id="distname">Normalize user names specified as X.500 distinguished names
in distributed identity filters</h4>
<p>[[[[ Contributing writer: Terry Merrill/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: George Markouizos/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: RACF provides distributed identity filters
in support of z/OS identity propagation. Before z/OS V1R13, RACF removed
leading and trailing blank characters before storing the user name
value of a distributed identity filter when you specified the user
name as an X.500 distinguished name (DN). Starting in z/OS V1R13,
RACF normalizes the user name before storing it in the RACF database.
The normalization process includes removing leading and trailing blank
and null characters from each relative distinguished name (RDN) of
the DN.</p>
<p><a id="idx1237"></a><a id="idx1238"></a><a id="idx1239"></a></p>
<table id="wq635" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Security Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13, and rolled back to z/OS V1R12 by
APAR OA34259.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12 with APAR OA34259 applied..</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> 

<ul>
<li> Before installing V2R1 for determining if your installation has
already defined any distributed identity filters. Go to <a href="e0z3m100.htm#e0z3m100-gen137">Security Server actions to perform before installing z/OS V2R1</a> in
this migration action.</li>
<li>Before the first IPL of z/OS V1R13 for customizing and executing
the sample REXX exec IRR34258. Go to <a href="e0z3m100.htm#e0z3m100-gen139">Security Server actions to perform before the first IPL of
z/OS V2R1</a> in this
migration action.</li>
<li>After the first IPL of z/OS V1R13 for redefining a filter for
an X.500 user identity. Go to <a href="e0z3m100.htm#e0z3m100-gen141">Security Server actions to perform after the first IPL of z/OS
V2R1</a> in this migration action.</li></ul></td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your installation specified an X.500
DN as the user name of a distributed identity filter on a z/OS V1R12
system without the normalization function provided with APARs OA34259
and OA34258.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>If your installation specified an X.500 DN as
the user name of a distributed identity filter on a z/OS V1R12 system
without the normalization function provided with APAR OA34259, the
filter might not function properly in z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li>Documentation in the PTFs for APAR OA34259.</li>
<li>For information about how to use a distributed identity filter
to map distributed identities to a RACF user ID, see "Distributed
identity filters" in <cite>z/OS Security Server RACF Security Administrator&amp;apos;s Guide</cite>.</li>
<li>For details about the normalization rules, see the USERDIDFILTER
operand of the RACMAP command in <cite>z/OS Security Server RACF Command Language Reference</cite>.</li></ul>
<h3 id="e0z3m100-gen139">Security Server actions to perform before the first IPL of
z/OS V2R1</h3>
<p>This topic describes Security Server migration actions that you
can perform after you have installed z/OS V2R1
but before the first time you IPL. These actions might require the z/OS V2R1 level of code to be installed
but do not require it to be active.</p>
<p><a href="e0z3m100.htm#aq3cdcn1">Check for duplicate class names</a></p>
<p><a href="e0z3m100.htm#dt2mg467">Change CHOWN.UNRESTRICTED profile in the RACF UNIXPRIV class
from an existence check to an authorization check.</a></p>
<p><a href="e0z3m100.htm#e0z3m100-gen140">Normalize user names specified as X.500 distinguished names
in distributed identity filters</a></p>
<h4 id="dt2mg765">Check for duplicate class names</h4><a id="idx1240"></a><a id="idx1241"></a><a id="idx1242"></a><a id="idx1243"></a><a id="idx1244"></a><a id="idx1245"></a><a id="idx1246"></a>
<p><strong>Description</strong>: When new classes are
shipped with RACF, you should
verify that any installation-defined class names that have been added
to the class descriptor table (CDT) do not conflict with the new classes. <a id="idx1247"></a><a id="idx1248"></a><a id="idx1249"></a><a id="idx1250"></a><a id="idx1251"></a>
For a list of new classes shipped with RACF, see <cite>z/OS Summary of Message and Interface Changes</cite>.</p>
<table id="wq636" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Security Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you have user-defined classes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Verify that any installation-defined
class names that have been added to the class descriptor table (CDT)
do not conflict with the new classes.</p>
<ul>
<li>If you have duplicate class names, RACF issues the following message
and enters failsoft mode: 

<pre class="xmp"><code>ICH564A RACF DETECTED AN ERROR IN THE INSTALLATION CLASS DESCRIPTOR TABLE,
ENTRY <span class="synph"><span class="var">class_name</span></span>, ERROR CODE 7</code></pre></li>
<li>If a conflict in class names occurs, resolve it as follows:


<ol type="1">
<li>Delete the profiles in the installation-defined class with the
conflicting name.</li>
<li>Delete the CDT entry for the class.</li>
<li>Add a CDT entry with a different name.</li>
<li>Redefine the profiles.</li></ol></li></ul>
<p><strong>Reference information</strong>: See <cite>z/OS Security Server RACF System Programmer&amp;apos;s Guide</cite>.</p>
<h4 id="dt2mg766">Change CHOWN.UNRESTRICTED profile in the RACF UNIXPRIV class
from an existence check to an authorization check.</h4><a id="idx1252"></a>
<p></p>
<p><strong>Description</strong>: Starting in z/OS V2R1, ICSF will remove the
support for CCF and PCICC devices, which are only present on the z900
machine.</p>
<table id="wq638" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>Security
Server.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before
the first IPL.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No,
but recommended for system security.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>IRRXUTIL
to detect if the profile is present, and report on its UACC and access
list.  But a simple RLIST command will accomplish the same goal.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<p><strong>Reference information:</strong></p>
<h4 id="dt2mg767">Normalize user names specified as X.500 distinguished names
in distributed identity filters</h4><a id="idx1253"></a><a id="idx1254"></a><a id="idx1255"></a>
<p>Go to <a href="e0z3m100.htm#distname">Normalize user names specified as X.500 distinguished names
in distributed identity filters</a>.</p>
<h3 id="e0z3m100-gen141">Security Server actions to perform after the first IPL of z/OS
V2R1</h3>
<p>This topic describes Security Server migration actions that you
can perform only after you have IPLed z/OS V2R1.
You need a running z/OS V2R1
system to perform these actions.</p>
<p><a href="e0z3m100.htm#aq3dbte1">Update database templates</a></p>
<p><a href="e0z3m100.htm#e0z3m100-gen142">Normalize user names specified as X.500 distinguished names
in distributed identity filters</a></p>
<h4 id="dt2mg768">Update database templates</h4><a id="idx1256"></a><a id="idx1257"></a><a id="idx1258"></a><a id="idx1259"></a><a id="idx1260"></a><a id="idx1261"></a><a id="idx1262"></a>
<p><strong>Description</strong>: To ensure that the RACF utilities function properly,
use the IRRMIN00 utility to update the test and production RACF databases with the database
templates for the current release level.<a id="idx1263"></a><a id="idx1264"></a><a id="idx1265"></a></p>
<table id="wq639" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>Security Server.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: To install the database template
updates, run the IRRMIN00 utility with PARM=UPDATE.</p>
<div>
<div class="note-noindent" id="wq640">
<span class="notetitle">Note:</span> <span class="notebody">If IRRMIN00 produces a return code of 4 and message <samp class="xph">IRR8025
PARM=UPDATE specified, but template update not required</samp>, you
do not necessarily have a problem. Check that your JCL points to the
new level of IRRMIN00. If it does, ignore the return code and warning
message. A PTF might have already brought your templates up to the
current level for the new release. If your JCL accidentally points
to an old copy of IRRMIN00, correct the JCL and run IRRMIN00 again.</span></div></div>
<p><strong>Reference information</strong>: 

</p>
<ul>
<li><cite>z/OS Program Directory</cite></li>
<li><cite>ServerPac: Installing
Your Order</cite></li>
<li><cite>z/OS Security Server RACF System Programmer&amp;apos;s Guide</cite></li></ul>
<h4 id="dt2mg769">Normalize user names specified as X.500 distinguished names
in distributed identity filters</h4><a id="idx1266"></a><a id="idx1267"></a><a id="idx1268"></a>
<p>Go to <a href="e0z3m100.htm#distname">Normalize user names specified as X.500 distinguished names
in distributed identity filters</a>.</p>
<h2 id="ac1ccpp1">XL C/C++ migration actions</h2>
<p>This topic describes migration actions for optional feature C/C++
without Debug Tool.</p>
<div>
<div class="note-noindent" id="wq641">
<span class="notetitle">Note:</span> <span class="notebody">As of z/OS V1R7,
the C/C++ compiler has been rebranded to XL C/C++. However, the name
of the optional feature that contains the XL C/C++ compiler remains
C/C++ without Debug Tool.</span></div></div>
<h3 id="e0z3m100-gen145">XL C/C++ actions to perform before installing z/OS V2R1</h3><a id="idx1269"></a><a id="idx1270"></a>
<p>This topic describes XL C/C++ migration actions that you can perform
on your current (old) system. You do not need the z/OS V2R1 level of code to make these changes,
and the changes do not require the z/OS V2R1
level of code to run once they are made.</p>
<p><a href="e0z3m100.htm#revappl1">Review the XL C/C++ Migration Guide for the Application Programmer</a></p>
<h4 id="dt2mg772">Review the XL C/C++ Migration Guide for the Application Programmer</h4><a id="idx1271"></a><a id="idx1272"></a><a id="idx1273"></a><a id="idx1274"></a>
<p>[[[[ Contributing writer: James E Becker/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Requestor: Marna Walle/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: The publication 
<cite>z/OS XL C/C++ Compiler and Runtime Migration Guide for the Application Programmer</cite> is written for application programmers,
whereas this publication (<em>z/OS Migration</em>) is written for system programmers.
However, in some customer locations, job scope could overlap such
that system programmers might find information in the XL C/C++ publication
that is relevant to their responsibilities. For example, migration
information related to the c89 utility in the XL C/C++ publication
could be of interest. Therefore, you ought to review the XL C/C++
publication if you use XL C/C++.</p>
<table id="wq642" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>C/C++ without Debug Tool.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>General migration action not tied to a specific
release.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended if you use XL C/C++.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Look through 
<cite>z/OS XL C/C++ Compiler and Runtime Migration Guide for the Application Programmer</cite> for migration information that is relevant
to your installation.</p>
<p><strong>Reference information</strong>: <cite>z/OS XL C/C++ Compiler and Runtime Migration Guide for the Application Programmer</cite></p>
<h3 id="e0z3m100-gen146">XL C/C++ actions to perform before the first IPL of z/OS V2R1</h3>
<p>This topic describes XL C/C++ migration actions that you can perform
after you have installed z/OS V2R1
but before the first time you IPL. These actions might require the z/OS V2R1 level of code to be installed
but do not require it to be active.</p>
<p>None.</p>
<h3 id="e0z3m100-gen147">XL C/C++ actions to perform after the first IPL of z/OS V2R1</h3>
<p>This topic describes XL C/C++ migration actions that you can perform
only after you have IPLed z/OS V2R1.
You need a running z/OS V2R1
system to perform these actions.</p>
<p>None.<a id="idx1275"></a><a id="idx1276"></a><a id="idx1277"></a><a id="idx1278"></a><a id="idx1279"></a><a id="idx1280"></a></p>
<h2 id="font1">z/OS Base Font Collection migration actions</h2>
<p id="font1__d5">This topic describes migration actions for the base z/OS
Font Collection. z/OS Font Collection is a new z/OS base element for
z/OS V2R1.</p>
<h3 id="e0z3m100-gen148">z/OS Base Font Collection actions to perform before installing
z/OS V2R1</h3><a id="idx1281"></a>
<p>This topic describes z/OS Font Collection actions that you can
perform on your current (old) system. You do not need the z/OS V2R1 level of code to make
these changes, and the changes do not require the z/OS V2R1 level of code to run once they are
made.</p>
<p><a href="e0z3m100.htm#fontcol1">Stop using old fonts and start using the fonts from the z/OS
Font Collection</a></p>
<p>None.</p>
<h3 id="e0z3m100-gen149">z/OS Base Font Collection actions to perform before the first
IPL of z/OS V2R1</h3><a id="idx1282"></a>
<p>This topic describes z/OS Font Collection migration actions that
you can perform after you have installed z/OS V2R1 but before the first time you IPL. These
actions might require the z/OS V2R1
level of code to be installed but do not require it to be active.</p>
<h4 id="dt2mg775">Stop using old fonts and start using the fonts from the z/OS
Font Collection</h4>
<p>[[[[ Contributing writer: &lt;Example,
Jim Guilianelli/Poughkeepsie/IBM@IBMUS &gt; ]]]] [[[[ Technical contact: &lt;Example:
Marna Walle/Poughkeepsie/IBM@IBMUS &gt; ]]]]</p>
<p><strong>Description</strong>: z/OS V2R1 contains a new base element:  z/OS
Font Collection.  The z/OS Font Collection provides fonts that were
previously marketed and serviced for z/OS.  The z/OS Font Collection
will include both single-byte and double-byte fonts.</p>
<p>The z/OS Font Collection includes:  
</p>
<ul>
<li>AFP outline fonts.</li>
<li>AFP raster fonts, including a complete set of IBM expanded core
fonts and a set of Math, PI, and Sonoran 240-pel raster fonts.</li>
<li>TrueType and OpenType fonts. These fonts have not been made available
as a separate program product for z/OS before, and are an enhancement
as of z/OS V2R1.</li></ul>
<p>The following table summarizes the existing font programs
and whether the z/OS Font Collection base element can replace them
along with the replacement name in the collection:
</p>
<table id="dt2mg776" width="100%" summary="" border="1" frame="border" rules="all">
<caption><a href="e0z3m100.htm#FT_Table_16">Table 16. Existing font products and replacements in the z/OS Font Collection base element</a></caption>
<thead valign="bottom">
<tr valign="bottom">
<th id="wq643" width="15%" align="left">Program number</th>
<th id="wq644" width="25%" align="left">Product name</th>
<th id="wq645" width="7%" align="left">V.R.M.</th>
<th id="wq646" width="16%" align="left">ServerPac in Japan</th>
<th id="wq647" width="12%" align="left">PDO in Japan</th>
<th id="wq648" width="22%" align="left">Included in the V2R1 z/OS Font Collection as
base feature</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td headers="wq643">5655-M32</td>
<td headers="wq644">PSF V4 for z/OS</td>
<td headers="wq645">4.4.0</td>
<td headers="wq646">Orderable</td>
<td headers="wq647">Orderable</td>
<td headers="wq648">N/A</td>
</tr>
<tr>
<td headers="wq643">5655-M32</td>
<td headers="wq644">MVS Download</td>
<td headers="wq645">4.4.0</td>
<td headers="wq646">Orderable</td>
<td headers="wq647">Orderable</td>
<td headers="wq648">N/A</td>
</tr>
<tr>
<td headers="wq643">5655-M32</td>
<td headers="wq644">Enhanced ACIF</td>
<td headers="wq645">4.4.0</td>
<td headers="wq646">Orderable</td>
<td headers="wq647">Orderable</td>
<td headers="wq648">N/A</td>
</tr>
<tr>
<td headers="wq643">5655-M32</td>
<td headers="wq644">Compatibility Fonts</td>
<td headers="wq645">4.4.0</td>
<td headers="wq646">Orderable</td>
<td headers="wq647">Orderable</td>
<td headers="wq648">N/A</td>
</tr>
<tr>
<td headers="wq643">5655-M32</td>
<td headers="wq644">AFP Upload</td>
<td headers="wq645">4.4.0</td>
<td headers="wq646">Orderable</td>
<td headers="wq647">Orderable</td>
<td headers="wq648">N/A</td>
</tr>
<tr>
<td headers="wq643">5655-M32</td>
<td headers="wq644">AFP Download Plus</td>
<td headers="wq645">4.4.0</td>
<td headers="wq646">Orderable</td>
<td headers="wq647">Orderable</td>
<td headers="wq648">N/A</td>
</tr>
<tr>
<td headers="wq643">5648-B33</td>
<td headers="wq644">AFP Font Collection for MVS</td>
<td headers="wq645">2.1.1</td>
<td headers="wq646">Orderable</td>
<td headers="wq647">Orderable</td>
<td headers="wq648">HFNT110</td>
</tr>
<tr>
<td headers="wq643">5648-B33</td>
<td headers="wq644">Japanese Fonts for MVS</td>
<td headers="wq645">2.1.1</td>
<td headers="wq646">Orderable</td>
<td headers="wq647">Orderable</td>
<td headers="wq648">HFNT11J</td>
</tr>
<tr>
<td headers="wq643">5648-B33</td>
<td headers="wq644">Korean Fonts for MVS</td>
<td headers="wq645">2.1.1</td>
<td headers="wq646">Orderable</td>
<td headers="wq647">Orderable</td>
<td headers="wq648">HFNT11J</td>
</tr>
<tr>
<td headers="wq643">5648-B33</td>
<td headers="wq644">T-Chinese Fonts for MVS</td>
<td headers="wq645">2.1.1</td>
<td headers="wq646">Orderable</td>
<td headers="wq647">Orderable</td>
<td headers="wq648">HFNT11J</td>
</tr>
<tr>
<td headers="wq643">5648-B33</td>
<td headers="wq644">S-Chinese Fonts for MVS</td>
<td headers="wq645">2.1.1</td>
<td headers="wq646">Orderable</td>
<td headers="wq647">Orderable</td>
<td headers="wq648">HFNT11J</td>
</tr>
<tr>
<td headers="wq643">5648-E76</td>
<td headers="wq644">General Font Library</td>
<td headers="wq645">1.1.0</td>
<td headers="wq646">Orderable</td>
<td headers="wq647">Orderable</td>
<td headers="wq648">HFNT110</td>
</tr>
<tr>
<td headers="wq643">5648-E76</td>
<td headers="wq644">T Chinese Font Library</td>
<td headers="wq645">1.1.0</td>
<td headers="wq646">Orderable</td>
<td headers="wq647">Orderable</td>
<td headers="wq648">HFNT11J</td>
</tr>
<tr>
<td headers="wq643">5648-E76</td>
<td headers="wq644">S Chinese Font Library</td>
<td headers="wq645">1.1.0</td>
<td headers="wq646">Orderable</td>
<td headers="wq647">Orderable</td>
<td headers="wq648">HFNT11J</td>
</tr>
<tr>
<td headers="wq643">5648-E76</td>
<td headers="wq644">Korean Font Library</td>
<td headers="wq645">1.1.0</td>
<td headers="wq646">Orderable</td>
<td headers="wq647">Orderable</td>
<td headers="wq648">HFNT11J</td>
</tr>
<tr>
<td headers="wq643">5648-E76</td>
<td headers="wq644">Japanese Font Library</td>
<td headers="wq645">1.1.0</td>
<td headers="wq646">Orderable</td>
<td headers="wq647">Orderable</td>
<td headers="wq648">HFNT11J</td>
</tr>
<tr>
<td headers="wq643">5771-ABC</td>
<td headers="wq644">Pi and Specials Fonts Object</td>
<td headers="wq645">1.1.1</td>
<td headers="wq646">Orderable</td>
<td headers="wq647">Orderable</td>
<td headers="wq648">HFNT110</td>
</tr>
<tr>
<td headers="wq643">5771-ADT</td>
<td headers="wq644">Math and Science Fonts Object</td>
<td headers="wq645">1.1.0</td>
<td headers="wq646">Orderable</td>
<td headers="wq647">Orderable</td>
<td headers="wq648">HFNT110</td>
</tr>
</tbody>
</table>
<p><a id="idx1283"></a><a id="idx1284"></a></p>
<table id="wq649" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>z/OS Font Collection</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td> Yes, if you use standalone program products
for fonts with your z/OS system.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: The z/OS Font Collection - for migration
compatibility with previously available font program products - will
continue to use SYS1.FONTLIB and SYS1.FONTLIBB.  IBM recommends you
use the latest level of the fonts available for z/OS, and therefore,
those that are found in the z/OS Font Collection.  For that reason,
do not continue to use the standalone font program product data sets
with z/OS releases after z/OS V1R13.  No application or program changes
are anticipated.</p>
<p>Do not expect to order separately available font program
products with z/OS V2R1, or to install them into the z/OS V2R1 SMP/E
zones.  The z/OS Font Collection provides SMP/E statements to supercede
and delete the prior standalone program product levels of the fonts.</p>
<p><strong>Reference information</strong>: For details about the z/OS
Font Collection, see <cite>z/OS Font Collection</cite><cite> z/OS
Font Summary</cite>. For installation planning information, see <cite>z/OS Planning
for Installation</cite>.</p>
<h3 id="e0z3m100-gen150">z/OS Base Font Collection actions to perform after the first
IPL of z/OS V2R1</h3><a id="idx1285"></a>
<p>This topic describes z/OS Font Collection migration actions that
you can perform only after you have IPLed z/OS V2R1. You need a running
z/OS V2R1 system to perform these actions.</p>
<p>None.</p>
<h2 id="as1unss1">z/OS UNIX migration actions</h2>
<p>This topic describes migration actions for base element z/OS UNIX System
Services (z/OS UNIX).</p>
<h3 id="dt2mg777">z/OS UNIX actions to perform before installing z/OS
V2R1</h3><a id="idx1286"></a>
<p>This topic describes z/OS UNIX migration actions that you
can perform on your current (old) system. You do not need the z/OS V2R1 level of code to make
these changes, and the changes do not require the z/OS V2R1 level of code to run once they are
made.</p>
<p><a href="e0z3m100.htm#hfs2zfs1">Migrate from HFS file systems to zFS file systems</a></p>
<p><a href="e0z3m100.htm#unixapi1">Ensure that your applications do not use removed z/OS UNIX
APIs</a></p>
<p><a href="e0z3m100.htm#dt2mg491">Determine whether to accept the new default values for certain
zFS variables in the zFS IOEFSPRM configuration file</a></p>
<p><a href="e0z3m100.htm#dt2mg492">Accommodate the new Shell and Utilities version of the zlsof
utility</a></p>
<p><a href="e0z3m100.htm#zmountusr">Update invocations of /usr/sbin/mount commands</a></p>
<p><a href="e0z3m100.htm#binunmnt">Update invocations of /usr/sbin/unmount commands</a></p>
<p><a href="e0z3m100.htm#conscal">Discontinue use of z/OS UNIX System Services Connection
Scaling</a></p>
<h4 id="dt2mg781">Migrate from HFS file systems to zFS file systems</h4>
<p>[[[[ Contributing writer: Debra L Noll/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Ahilan Rajadeva/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: William Schoen/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Test contact: Robert Kindt/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R7,
the HFS file system was the primary hierarchical file system. As of
z/OS V1R7, you can use any combination of HFS and zFS file systems.
Because zFS has higher performance characteristics than HFS and is
the strategic file system, you should migrate your HFS file systems
to zFS.<a id="idx1287"></a><a id="idx1288"></a></p>
<p>The HFS and zFS file system types in mount statements and command
operands are now generic file system types that can mean either HFS
or zFS. Based on the data set type, the system will determine which
is appropriate. But note that you must still specify a type (HFS or
zFS and it cannot be defaulted), and if the type you specify is not
correct for the file system being mounted, any associated parameter
string setting in the mount statement or command is ignored, even
though the system sets the type correctly and processes the mount.</p>
<table id="wq650" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>zFS became the strategic file system in z/OS V1R7.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because the action is planned
to become a requirement in a future release. zFS is the strategic
file system for z/OS UNIX and
continues to be enhanced to provide superior performance, reliability,
and data integrity.

<p>z/OS V2R1 will support HFS file systems.</p></td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>
<ul>
<li>Understand the zFS recommendations and limits. For more information,
see "Minimum and maximum file system sizes" in <cite>z/OS Distributed File Service zFS Administration</cite> and <cite>z/OS Distributed File Service zFS Administration</cite></li>
<li>The DDNAME() keyword of the BPXPRMxx ROOT and MOUNT statements
is not supported by zFS. Use the FILESYSTEMNAME(<em>name</em>) keyword
instead.</li></ul></td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>Use check USS_HFS_DETECTED to verify all file
systems mounted. This check issues exception message BPXH068E if any
HFS file systems are found.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Before beginning the migration, do the following: 

<ul>
<li>Establish backout procedures.</li>
<li>Decide on naming conventions.</li>
<li>Decide on unavailability.</li>
<li>Understand any cloning or deployment changes required by zFS systems
being linear data sets. Considerations would include any copy utility
invocations, BPXPRMxx specifications for symbolics, and placement
of zFS file systems on system volumes.</li></ul></li>
<li>Perform the conversion from an HFS to zFS file system. 

<p><strong>Tip</strong>:
Use the BPXWH2Z tool to perform the conversion. It is an ISPF-based
tool that migrates HFS file systems to zFS file systems. Using its
panel interface, you can alter the space allocation, placement, SMS
classes, and data set names. A HELP panel is provided. With this tool,
you can: 
</p>
<ul>
<li>Migrate HFS file systems (both mounted and unmounted) to zFS file
systems. If the HFS being migrated is mounted, the tool automatically
unmounts it and then mounts the new zFS file system on its current
mount point.</li>
<li>Define zFS aggregates by default to be approximately
the same size as the  HFS. The new allocation size can also be increased
or decreased. In z/OS V1R13, ZFS could require up to four times (4X)
the space that HFS did; therefore, for z/OS V2R1 be sure to allocate
more space. See <a href="e0z3m100.htm#newdasd">zFS: Accommodate new DASD space requirements</a>.</li>
<li>Have the migration run in TSO foreground or UNIX background.</li></ul> 

<p>You can use the JCL sample ISPBTCH in SYS1.SAMPLIB
to invoke BPXWH2Z as an ISPF batch job. Before you run the job, read
the <strong>Notes</strong> section. When you run BPXWH2Z on your z/OS system,
make sure it uses that same z/OS level of the pax command. You can
manually migrate from an HFS to zFS file system without using the
tool. However, you would need to allocate and format the target zFS
file systems.</p> 

<p><strong>Requirement</strong>: The BPXWH2Z tool requires
the zFS address space to be operational. Therefore, before attempting
to migrate existing HFS to zFS file systems using BPXWH2Z, make sure
that the zFS address space has been successfully configured and initialized.</p> 

<p><strong>Tip</strong>: You can dynamically migrate the HFS sysplex root
in a shared file system configuration to zFS while the root is in
use, without disrupting workloads. Although the shared file system
configuration is required, the sysplex can be a single system. For
the steps involved in migrating the sysplex root file system from
HFS to zFS, see below.</p></li>
<li>Change policies and scripts, and so forth, to reflect
the change from the HFS file system to zFS file system. Use the RMF
Monitor III option to report on zFS activity. Refer to migration action
"Monitor the zFS file system activity" for information on gathering
zFS activity in RMF Monitor III. 

<p><strong>Tip</strong>: Use the RMF Monitor III option to report on zFS activity.</p>
<div>
<div class="note-noindent" id="wq652">
<span class="notetitle">Note:</span> <span class="notebody">Beginning
in z/OS V2R1, the default of RMF Monitor III option was changed to
NOZFS. So, you need to explicitly specify ZFS option.</span></div></div></li>
<li>he DDNAME(<em>name</em>) keyword of the BPXPRMxx ROOT and
MOUNT statements is not supported by zFS. If you use them. change
these statements to use the FILESYSTEMNAME(<em>name</em> keyword instead.</li></ol>
<p id="dt2mg782"><strong>Migrating the sysplex root file system from HFS
to zFS after IPL of z/OS</strong>:</p>
<p><a id="idx1289"></a>Before
you begin the migration: 
</p>
<ul>
<li>Ensure that the following requirements have been met: 

<ul>
<li>The current sysplex root file system PFS, and the new sysplex
root file system PFS, are up in all the systems in shared file system
configuration.</li></ul></li>
<li>Be aware of the following restrictions: 

<ul>
<li>The current sysplex root file system must be mounted as a read-only
file system.</li>
<li>The systems that do not meet the requirements for this migration
action cannot join the sysplex during the sysplex root file system
migration processing, but they can join the sysplex after the sysplex
root migration has completed.</li>
<li>The current sysplex root and the new sysplex root must be either
HFS or zFS in any combination. If the new sysplex root is zFS, then
 it must be HFS-compatible.</li>
<li>The sysplex root or any directories on it cannot have been exported
by the DFS or
SMB server.</li></ul></li>
<li>Note the following: 

<ul>
<li>Remote NFS mounts of the sysplex root or any directories on it
are considered active use of the current sysplex root file system.</li>
<li>During the migration, the new zFS sysplex root file system must
not be HSM-migrated, mounted, or in use.</li>
<li>Mount parameters are preserved during the migration or replacement
of the sysplex root file system of the same file system type (PFS).
They are dropped if the file system type is different.</li>
<li>Directories, data, files, and links are not copied from one file
system to another.</li></ul></li></ul>
<p>Perform the migration as follows:</p>
<ol type="1">
<li>Ensure that a file system has been mounted read-only as the current
sysplex root file system. When the root is mounted read-only, there
are no function-shipping clients as long as physical paths to the
DASD are available to each system. To verify that there are no function-shipping
clients, issue:  
<pre class="xmp"><code>D OMVS,F,NAME=root_file_system_name</code></pre> You
should see CLIENT=N on each system.</li>
<li>Allocate and set up the new zFS sysplex root file system:  

<ol type="a">
<li>Create a new zFS file system to be used as the new sysplex root
file system. <cite>z/OS Distributed File Service zFS Administration</cite> discusses
creating and managing zFS file systems.  

<p><strong>Rules</strong>:
 
</p>
<ul>
<li>The UID, GID and the permission bits of the root directory in
the new sysplex root file system must be same as the root directory
in the current sysplex root file system.</li>
<li>If the SECLABEL class is active and the MLFSOBJ option is active,
the security label for the new zFS file system must match the assumed
security label of the current sysplex root file system.</li></ul></li>
<li>On the new sysplex root file system, set up the active mount points
and the symbolic links. The mount points and symbolic links must be
the same as the ones on the current sysplex root file system. You
can set them up either (1) manually or (2) by using the <span class="synph"><span class="kwd">pax</span></span> shell
command to populate the new sysplex root file system using the existing
sysplex root as a source. To do it manually, create a mount point
in the existing sysplex root (for example, /newroot) and mount the
new sysplex root file system in the MODE(RDWR) on that mount point.
After mounting the new sysplex root file system, manually issue MKDIRs
and ln -s to create the mount point directories and symbolic links
similar to the existing sysplex root file system. Note that the new
sysplex root file system must contain all active mount points and
symbolic links exactly as on the existing sysplex root file system.</li>
<li>Use the <span class="synph"><span class="kwd">pax</span></span> shell command to populate
the new file system, using the existing sysplex root as a
source. 

<p><strong>Example</strong>:  </p>
<pre class="xmp"><code>cd /
pax -wr -pe -XCM ./ /newroot</code></pre><p class="indatacontent"> For more information about
using <span class="synph"><span class="kwd">pax</span></span> to copy data from an HFS file
system to a zFS file system, see <cite>z/OS Distributed File Service zFS Administration</cite>.</p></li>
<li>Unmount the new zFS file system.</li></ol></li>
<li>On any system in the shared file system configuration, issue: 
<pre class="xmp"><code>F OMVS,NEWROOT=new.root.file.system.name,COND=&lt;Yes|No&gt;</code></pre>  

<dl>
<dt class="bold">YES</dt>
<dd>Proceed conditionally. The system checks for active usage in the
current sysplex root file system and reports the active usage in a
BPXF245I message. If file activity is found, the command fails
with EBUSY return code and JrActivityFound reason code. If file activity
is not found, the command continues processing to replace the sysplex
root. YES is the default.
</dd>
<dt class="bold">NO</dt>
<dd>Proceed unconditionally. The system checks for active usage in
the current sysplex root file system and reports the active usage
in a BPXF245I message. Replacement of the sysplex root file
system will continue.
</dd>
</dl>The migration of  the sysplex root file system will
begin. During the migration, active connections to files and directories
in the current sysplex root file system are broken. 

<p>After the migration
completes:</p> 

<ul>
<li>The root CWD(&lsquo;/&rsquo;) is updated on all systems in the sysplex to
point to the new sysplex root file system.</li>
<li>New opens go to the new sysplex root file system.  The current
sysplex root for the root directory is replaced for all  processes
in all systems.  The current directory for root directory is replaced
for any processes using it</li>
<li>Old connections in the previous sysplex root file system might get
EIO errors.</li></ul></li>
<li>Update the TYPE parameter and name of the sysplex root
file system in the BPXPRM<span class="synph"><span class="var">xx</span></span> member of SYS1.PARMLIB.</li>
<li>Because the DDNAME() keyword of the BPXPRMxx ROOT and
MOUNT statements is not supported by zFS, change these statements
to use the FILESYSTEMNAME(<em>name</em>) keyword instead.</li></ol>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li>For more information about the HFS and zFS file systems, see <cite>z/OS UNIX System Services Planning</cite>.</li>
<li>To read about setting up zFS, see <cite>z/OS Distributed File Service zFS Administration</cite>.</li>
<li>For information about the <strong>pax</strong> command, see <cite>z/OS UNIX System Services Command Reference</cite>.</li></ul>
<h4 id="dt2mg783">Ensure that your applications do not use removed z/OS UNIX
APIs</h4><a id="idx1290"></a><a id="idx1291"></a><a id="idx1292"></a><a id="idx1293"></a>
<p>[[[[ Debbie Noll: ]]]] [[[[ Duane Hughes]]]]</p>
<p><strong>Description</strong>: Before z/OS V2R1, certain z/OS UNIX application
programming interfaces (APIs) were available. Starting in z/OS V2R1,
they are no longer available. <a id="idx1294"></a></p>
<table id="wq655" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if your installation has C/C++ or Assembler
language applications that explicitly invoke z/OS UNIX application
programming interfaces.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>This change does not affect the z/OS system
itself but might cause applications or products other than z/OS to
give erroneous results or behave unexpectedly.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Check three interfaces to see if the removed
services are being used.</p>
<ol type="1">
<li>Scan the source code for use of the following z/OS UNIX application
programming interfaces: 

<ul>
<li>The _osenv() syscall 

<ul>
<li>For Assembler language programs, search for BPX1OSE and BPX4OSE.</li>
<li>For C or C++ code, search for calls to the _osenv() service.</li></ul></li>
<li>The pthread_quiesce_and_get_np() syscall 

<ul>
<li>For Assembler language programs, search for BPX1PQG and BPX4PQG.</li>
<li>For C or C++ code, search for calls to the pthread_quiesce_and_get_np()
service.</li></ul></li>
<li>The QUICK_FREEZE_EXIT_REG option of oe_env_np() 

<ul>
<li>For Assembler language programs, search for BPX1ENV and BPX4ENV.</li>
<li>There is no C/C++ interface that allows direct use of the QUICK_FREEZE_EXIT_REG
option. If you find use of the BPX1ENV or BPX4ENV service, check whether
the QUICK_FREEZE_EXIT_REG option is specified. If you do use this
option, verify that you have code that invokes the pthread_quiesce_and_get_np()
service (in XL C/C++) or calls BPX1PQG or BPX4PQG. If you do not have
code that calls the pthread_quiesce_and_get_np() service, then you
do not need to invoke the BPX1ENV or BPX4ENV service with the QUICK_FREEZE_EXIT_REG
option. Remove that call from your application.</li></ul></li></ul></li>
<li>If your applications use any of these interfaces, update the applications
to either eliminate the calls or handle the new return code and reason
code that the removed interfaces will return.</li></ol>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li><cite>z/OS UNIX System Services Programming: Assembler Callable Services Reference</cite></li>
<li><cite>z/OS XL C/C++ Runtime Library Reference</cite></li></ul>
<h4 id="dt2mg784">Determine whether to accept the new default values for certain
zFS variables in the zFS IOEFSPRM configuration file</h4><a id="idx1295"></a>
<p></p>
<p><strong>Description</strong>: Before z/OS V2R1, certain default values were
used for the IOEFSPRM files or IOEPRMxx parmlib member variables <samp>meta_cache_size</samp>, <samp>metaback_cache_size</samp>, <samp>user_cache_size</samp>,
or <samp>convert_auditfid</samp>. Starting in z/OS V2R1, new default
values are created for them.</p>
<table id="wq657" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you do not want to continue accepting
the default values for the zFS configuration variables or if you have
provided values for these configuration variables.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>If enough real storage exists, zFS can use more
storage by default than it would have used in prior releases.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:
</p>
<ul>
<li>Look for these:

<ul>
<li>IOEFSPRM files or IOEPRMxx parmlib members that do not specify
both <samp>meta_cache_size</samp> and <samp>metaback_cache_size</samp> options.</li>
<li>IOEFSPRM files or IOEPRMxx parmlib members that do not specify
the <samp>user_cache_size</samp> option.</li>
<li>IOEFSPRM files or IOEPRMxx parmlib members that do not specify <samp>convert_auditfid</samp> settings.</li>
<li>Programs that use <strong><samp>zfsadm format</samp></strong> commands where
unique auditfids are not desired.</li>
<li>JCL that contains calls to<strong><samp> ioeagfmt</samp></strong> that create
aggregates for which unique auditfids are not desired.</li>
<li>Programs that use zFS format API where unique auditfids are not
desired.</li></ul></li>
<li>Take these actions:

<ul>
<li>For <samp>meta_cache_size</samp>, <samp>metaback_cache_size</samp>,
or <samp>user_cache_size</samp>, if the old default values are
desired, specify these values in your IOEFSPRM files or IOEPRMxx parmlib
members.</li>
<li>For auditfid, if you want the previous defaults, specify <samp>-nonewauditfid</samp> on
calls to <strong><samp>ioeagfmt</samp></strong> or <strong><samp>zfsadm format</samp></strong> and <samp>convert_auditfid=OFF</samp> in
your IOEFSPRM files or IOEPRMxx parmlib members.</li></ul></li></ul>
<p><strong>Reference information</strong>: For more information about zFS, see<cite>z/OS Distributed File Service zFS Administration</cite>.</p>
<h4 id="dt2mg785">Accommodate the new Shell and Utilities version of the zlsof
utility</h4><a id="idx1296"></a>
<p></p>
<p><strong>Description</strong>: Before
z/OS V2R1, the <strong><samp>zlsof</samp></strong> utility was obtained from
the Tools and Toys section of the z/OS UNIX website. Starting in z/OS
V2R1, Shell and Utilities support of the <strong><samp>zlsof</samp></strong> utility
has been added. The supported version differs from the Tools and Toys
version in a number of ways. For example, the new <strong><samp>zlsof</samp></strong> 
version includes support for displaying file lock holders and waiters
when the byte range lock manager is used.:</p>
<table id="wq658" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before installing z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you currently use the Tools and Toys
version of the <strong><samp>zlsof</samp></strong> utility.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Look for current use of the Tools and Toys
version of <strong><samp>zlsof</samp></strong>. If there is no current use of
the Tools and Toys version of <strong><samp>zlsof</samp></strong>, then no actions
or changes are required.</p>
<p>If there is current usage of the Tools and Toys version of <strong><samp>zlsof</samp></strong>,
determine if the command is in <samp>/bin</samp>, or in another
directory. Also, determine if you want to preserve the Tools and Toys
version in addition to the officially shipped version. Note that <strong><samp>zlsof</samp></strong> can
also reside in data sets where rexx execs can be run.
</p>
<ol type="1">
<li>If you want to preserve the Tools and Toys version, ensure
that you save it into a directory that z/OS V2R1 will not install
into. z/OS V2R1 provides <strong><samp>zlsof</samp></strong> in the <samp>/bin</samp> directory.</li>
<li id="dt2mg786">If you do not want to preserve the Tools and Toys
version and it is in <samp>/bin</samp>, then the installation
of z/OS V2R1 automatically replaces the Tools and Toys version with
the new officially supported version.  If the Tools and Toys version
is not in <samp>/bin</samp>, remove it from its current location.</li></ol>
<p><strong>Reference information:</strong> For details about the <strong><samp>zlsof</samp></strong> command,
see <cite>z/OS UNIX System Services Command Reference</cite>.</p>
<h4 id="zmountusr">Update invocations of /usr/sbin/mount commands</h4>
<p>[[[[ Contributing writer: Debra L Noll/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contacts: Daniel Acevedo/Poughkeepsie/IBM@IBMUS,
Ahilan Rajadeva/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13, when using
the <span class="synph"><span class="kwd">/usr/sbin/mount</span></span> command with the <span class="synph"><span class="kwd">-o</span></span> <span class="synph"><span class="var">fsoptions</span></span> option,
that option was ignored for zFS file systems if the <span class="synph"><span class="kwd">-t</span></span> option
was not used to specify the file system type. Starting with z/OS V1R13,
the <span class="synph"><span class="kwd">-o</span></span> <span class="synph"><span class="var">fsoptions</span></span> option is not ignored in
that situation, which might cause the mount to (1) fail or (2) proceed
but with possible unintended results. <a id="idx1297"></a></p>
<table id="wq660" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, because invocations of <span class="synph"><span class="kwd">/usr/sbin/mount</span></span> 
might fail , or if the mount does not fail, the results might be unpredictable.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker
for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If you have invocations of
the <span class="synph"><span class="kwd">/usr/sbin/mount</span></span> command that do not use the <span class="synph"><span class="kwd">-t</span></span> option
to specify the file system type but specifies zFS-specific
options using the <span class="synph"><span class="kwd">-o</span></span> <span class="synph"><span class="var">fsoptions</span></span> option, take
the following actions:</p>
<ol type="1">
<li>If you want to keep the <span class="synph"><span class="kwd">-o</span></span> <span class="synph"><span class="var">fsoptions</span></span> option,
determine the type of the file system and specify it, using the <span class="synph"><span class="kwd">-t</span></span> option.</li>
<li>If the file system is zFS, verify that the options string that
was specified in <span class="synph"><span class="kwd">-o</span></span> <span class="synph"><span class="var">fsoptions</span></span> is valid.</li></ol>
<p><strong>Reference information</strong>: 

</p>
<ul>
<li>See the  in <cite>z/OS UNIX System Services Command Reference</cite>.</li>
<li>See the section on  in <cite>z/OS UNIX System Services Planning</cite>.</li></ul>
<h4 id="binunmnt">Update invocations of /usr/sbin/unmount commands</h4>
<p>[[[[ Contributing writer: Debra L Noll/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Ahilan Rajadeva/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13, if a path name was specified
when using the <span class="synph"><span class="kwd">/usr/sbin/unmount</span></span> command
to unmount a file system, the path name could be (1) any file or directory
in the file system or (2) the mount point of the file system. Starting
in z/OS V1R13, when the <span class="synph"><span class="kwd">/usr/sbin/unmount</span></span> command
is issued, only the mount point can be specified for the path name.</p>
<p>Unmounting based on using any file or directory in a file
system can sometimes cause the wrong file system from being unmounted.
There can be instances, for example, where the file system has already
been unmounted and a subsequent unmount on the same path name would
result in accidentally unmounting the wrong file system. <a id="idx1298"></a></p>
<table id="wq662" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, because invocations of <span class="synph"><span class="kwd">/usr/sbin/unmount</span></span> 
might fail if the path name is not the name of the mount point.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>If the path name is not the name of the mount
point, the following message is displayed: FOMF0512I Path is not a
mountpoint: <span class="synph"><span class="var">path-name</span></span>.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If you have invocations of the <span class="synph"><span class="kwd">/usr/sbin/unmount</span></span> command
that do not specify a mount point on the <span class="synph"><span class="var">name...</span></span> parameter,
follow these steps:</p>
<ol type="1">
<li>Look for instances where the specified path names in <span class="synph"><span class="kwd">/usr/sbin/unmount</span></span> invocations
are files or directories.</li>
<li>Select one of the following actions: 

<ul>
<li>Use the <strong> -m</strong> option in <span class="synph"><span class="kwd">/usr/sbin/unmount</span></span> command
if you have confirmed that something other than mount point needs
to be specified.  Note the file system that contains the file or the
directory will be unmounted.</li>
<li>Change the invocation so that only mount points are specified
for the path name.</li></ul></li></ol>
<p><strong>Reference information</strong>: See the <span class="synph"><span class="kwd">unmount</span></span> command
in <cite>z/OS UNIX System Services Command Reference</cite> for
further information.</p>
<h4 id="conscal">Discontinue use of z/OS UNIX System Services Connection
Scaling</h4>
<p>[[[[ Contributing writer: Debra L Noll/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Marna Walle/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>:  Starting with z/OS V1R13, support
of z/OS UNIX System Services Connection Scaling, specifically
the Connection Manager and Process Manager components, is discontinued.
FMID HCMG110, JCMG1J0, HPMG110, and JPMG1J0 are removed from z/OS
V1R13.<a id="idx1299"></a><a id="idx1300"></a><a id="idx1301"></a></p>
<table id="wq664" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13
(previewed in z/OS V1R12 Software Announcement 210-235, dated July
22, 2010).</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td> Before installing V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you use z/OS UNIX System Services Connection
Scaling.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take: </strong> Discontinue use of z/OS UNIX System
Services Connection Scaling. z/OS UNIX System Services Connection
Scaling consists of these FMIDs:  HCMG110 (Connection Manager), JCMG1J0
(Connection Manager Japanese), HPMG110 (Process Manager), and JPMG1J0
(Process Manager Japanese).</p>
<p><strong>Reference information</strong>: None</p>
<h3 id="e0z3m100-gen152">z/OS UNIX actions to perform before the first IPL
of z/OS V2R1</h3>
<p>This topic describes z/OS UNIX migration actions that you
can perform after you have installed z/OS V2R1
but before the first time you IPL. These actions might require the z/OS V2R1 level of code to be installed
but do not require it to be active.<a id="idx1302"></a><a id="idx1303"></a><a id="idx1304"></a><a id="idx1305"></a><a id="idx1306"></a><a id="idx1307"></a></p>
<p><a href="e0z3m100.htm#smf921">Update applications that use SMF type 92 subtype 11 close records</a></p>
<p><a href="e0z3m100.htm#dt2mg497">Remove ICLI component from z/OS</a></p>
<p><a href="e0z3m100.htm#dt2mg499">Determine if any sticky bit files or external links in your
z/OS UNIX file system are involved with link-edited MVS programs with
AC=1 (Part 1 before the first IPL of V2R1)</a></p>
<p><a href="e0z3m100.htm#bpxmount">Update invocations of MOUNT statements in the BPXPRMxx parmlib
member</a></p>
<p><a href="e0z3m100.htm#symblinks">Accommodate changes to support read-only z/OS
root for the z/OS UNIX System Services cron, mail, and uucp utilities</a></p>
<h4 id="dt2mg791">Update applications that use SMF type 92 subtype 11 close records</h4>
<p>[[[[ Debbie Noll: ]]]] [[[[ Daniel Acevedo]]]]</p>
<p><strong>Description</strong>: Before z/OS V2R1, SMF type 92, subtype
11 close records were written when sockets or character special records
were closed. Sockets and character special files have very high close
rates and do not provide useful information in determining how often
files and directories are used. Starting in z/OS V2R1, they are written
as subtype 16 close records instead. The sockets and character special
file close records will no longer appear in type 92 subtype 11 records.
Instead, you need to include type 92 subtype 16 records in the SMFPRMxx
parmlib member to collect them.<a id="idx1308"></a></p>
<table id="wq665" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Beforethe first IPL z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if you want continue to get close records
for sockets and character special files.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>:</p>
<ol type="1">
<li>Determine whether you have applications that use SMF type 92 subtype
11 close records. For those applications, SMF92TYP is set to SMF92#CLOSE
(11) for subtype 11. SMF92CTY is set to FT_SOCKET (7) for sockets
and FT_CHARSPEC (2) for character special files.</li>
<li>Change the application to look at subtype 16 records. SMF92TYP
will be set to SMF92#CLSSOCCHARSPEC (16).</li></ol>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li><cite>z/OS UNIX System Services Planning</cite></li></ul>
<h4 id="dt2mg792">Remove ICLI component from z/OS</h4><a id="idx1309"></a><a id="idx1310"></a>
<p>[[[[ Contributing writer: Jim Guilianelli]]]]
[[[[ Original technical contact: Greg Callis/Raleigh/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: IBM intends to remove the Integrated Call Level
Interface (ICLI) in z/OS z/OS V2R1. ICLI is used by those who have
requested and obtained the ICLI API documentation and the C language
header file. IBM believes that users of this interface have changed
from using ICLI to standard IBM DB2 Connect for database connectivity
and do not need it when z/OS V2R1 becomes available. ICLI has not
been enhanced since z/OS 1.6. IBM intends to exclude ICLI from releases
after z/OS V1R13.</p>
<p>Also see <a href="e0z3m100.htm#dt2mg340">IP Services: Remove ICLI component from z/OS</a>.</p>
<table id="wq667" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td align="left">Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended because ICLI is planne dto
be removed in a future release.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>ZOSMIGV2R1_CS_GATEWAY can help you determine
if you are using any GATEWAY statements in your TCP/IP profile.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Remove the ICLI component. To identify the
ICLI components examine the ibmicli.h header file?????????? Contact
your IBM representative if you have questions?</p>
<p><strong>Reference information:</strong> None.</p>
<h4 id="dt2mg793">Determine if any sticky bit files or external links in your
z/OS UNIX file system are involved with link-edited MVS programs with
AC=1 (Part 1 before the first IPL of V2R1)</h4><a id="idx1311"></a>
<p> [[[[ Contributing writer: Debra L Noll/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: Mike Spiegel/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Starting in z/OS V2R1, the invocation requirements
for MVS load library programs invoked through the z/OS UNIX spawn,
exec and attach_exec services have changed. These changes apply to
the invocation of MVS programs link-edited AC=1 found in an APF-authorized
library and for MVS load library programs that are to run as a z/OS
UNIX set-user-id or set-group-id program.  The following list describes
the changes: 
</p>
<ul>
<li>If the z/OS UNIX <em>pathname</em> that is supplied
to spawn,  exec or attach_exec represents an external link that resolves
to an MVS program found in an APF-authorized library and link-edited
with the AC=1 attribute, the external link must have an owning UID
of 0 and not be found in a file system that is mounted as NOSECURITY
to allow this type of invocation.</li>
<li>If the z/OS UNIX <em>pathname</em>  that is supplied
to spawn, exec, or attach_exec represents a regular file with the
sticky bit attribute that resolves to an MVS program found in an APF-authorized
library and link-edited with the AC=1 attribute, the sticky bit file
must have an owning UID of 0 or have the APF extended attribute turned
on to allow this type of invocation. Additionally, the sticky bit
file must not be found in a file system that is mounted as NOSECURITY
to allow this type of invocation.</li>
<li>If the z/OS UNIX <em>pathname</em> that supplied to
spawn, exec or attach_exec represents a symbolic link to a regular
file with the sticky bit attribute and the sticky bit file has the
set-user-id attribute, the symbolic link must have an owning UID of
0 or an owning UID equal to that of the sticky bit file.  If the sticky
bit file has the set-group-id attribute, the symbolic link must have
an owning UID of 0 or an owning GID equal to that of the sticky bit
file. Additionally, the symbolic link must not be found in a file
system that is mounted as NOSECURITY to allow this type of invocation.</li></ul>
<table id="wq668" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12  without APAR OA41101
applied.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>Before the first IPL of V2R1. (For steps to
take after the first IPL of z/OS V2R1, see .)</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended even though most, if not
all, IBM and vendor products install their executable files into the
z/OS UNIX file system with an owning UID of 0, so few, if any, executable
files on a customer system should have a problem.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>See <strong>Steps to take</strong>.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take before the first IPL</strong>: If you are
migrating a z/OS system from z/OS V1R12 or z/OS V1R13 with APAR OA41101
installed, then no migration actions need to be taken.   In this case,
it is assumed that you have taken all required actions related to
this APAR. Also see the documentation APAR OA41490.</p>
<p>If you are migrating from a z/OS system that does not have OA41101
installed and use the following IBM products, then you should ensure
that you have the latest service levels and have followed the most
recent install documentation for these IBM products:
</p>
<ul>
<li>IBM z/OS Problem Determination Tools File Manager Software V10
(see Doc APAR PM81080)</li>
<li>IBM z/OS Problem Determination Tools File Manager Software V11.1.0
with upgrade subset HADLB10 (ensure that PTF UK91613 is installed)</li>
<li>IBM z/OS Problem Determination Tools Common Component Software
V1.6.0 with upgrade subset HVWR160 (ensure that PTF UK91612 is installed)</li>
<li>IBM InfoSphere Data Replication (see Doc APAR PM81306)</li>
<li>IBM Security zSecure Suite (See Technote 1625364)</li>
<li>IBM Tivoli Security Information and Event Manager (see Technote
1626384)</li></ul>
<p>You may have to change the installation of some z/OS UNIX files
and links provided by these products.</p>
<p>Otherwise, if you follow the standard install process for z/OS
UNIX software, then you should not need to make any further changes
related to APAR OA41101. Exceptions to this would be: 
</p>
<ul>
<li>If you installed z/OS UNIX sticky bit files, symbolic links or
external links for any of your own software without using SMP/E</li>
<li>If you installed any IBM or other vendor provided z/OS UNIX sticky
bit files, symbolic links or external links outside the normal SMP/E
install process</li>
<li>If you installed z/OS UNIX software using SMP/E from a user that
is not running with UID 0 and is not permitted to BPX.SUPERUSER</li></ul>
<p>If any of these exceptions exist on your system, then you might
have to change the installation of these files and links.   To identify
all the sticky bit files, symbolic links and external links that need
to change, you need to IPL with z/OS V2R1 installed.   If any of these
files or links are executed,  you will then start seeing  EC6-xxxxC04A
abends along with message BPXP028I in the system log, which identifies
the files or links that must be changed.    You can then use the documentation
for message BPXP028I to correct the files or links that are installed
improperly.  For more information about message BPXP028I, see <cite>z/OS MVS System Messages, Vol 3 (ASB-BPX),</cite>.</p>
<p>For steps to take after the first IPL, see <a href="e0z3m100.htm#dt2mg502">Determine if any sticky bit files or external links in your
z/OS UNIX file system are involved in the invocation of MVS programs
that are link-edited with the AC=1 attribute (Part 2 after IPL of
z/OS V2R1)</a></p>
<p><strong>Reference information:</strong> <cite>z/OS UNIX System Services Command Reference</cite>.</p>
<h4 id="bpxmount">Update invocations of MOUNT statements in the BPXPRMxx parmlib
member</h4>
<p> [[[[ Contributing writer: Debra L Noll/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: John H Case/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13, if the MOUNT
statement in the BPXPRM<span class="synph"><span class="var">xx</span></span> member of SYS1.PARMLIB was first
processed by a system other than the specified target owner, the MOUNT
processing was function-shipped to the target owner. Starting
with z/OS V1R13, if the MOUNT statement specifies a SYSNAME() keyword,
the mount request is ignored during file system initialization and
F BPXOINIT,FILESYS=REINIT processing if the SYSNAME() value specifies
a different target owner system. The file system is then automatically
mounted locally after the MOUNT statement is processed on the target
system. The MOUNT statements in BPXPRM<span class="synph"><span class="var">xx</span></span> continues to be
processed as part of SET OMVS and SETOMVS command processed without
any changes; that is, the MOUNT processing continues to be function-shipped
to the specified SYSNAME() target owner system.<a id="idx1312"></a></p>
<table id="wq669" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, because required file systems might not
be mounted.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker
for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If you have a BPXPRM<span class="synph"><span class="var">xx</span></span> parmlib
member that contains MOUNT statements with a SYSNAME() keyword specifying
a specific target name, select one of the following actions:</p>
<ol type="1">
<li>Verify that the BPXPRM<span class="synph"><span class="var">xx</span></span> member is also specified as
a z/OS UNIX parmlib member for the specified target systems.</li>
<li>Move the MOUNT statements from that BPXPRM<span class="synph"><span class="var">xx</span></span> member to
a BPXPRM<span class="synph"><span class="var">xx</span></span> member that is used by the target owner system.</li></ol>
<p>Note that specifying SYSNAME(&amp;SYSNAME) always resolves to the
system name of the local system; the MOUNT statement is processed
as a result.</p>
<p><strong>Reference information</strong>: See "Customizing
BPXPRM<span class="synph"><span class="var">xx</span></span> for a shared file system" in <cite>z/OS UNIX System Services Planning</cite> for
a description of the  keyword for the BPXPRM<span class="synph"><span class="var">xx</span></span> MOUNT
statement.</p>
<h4 id="symblinks">Accommodate changes to support read-only z/OS
root for the z/OS UNIX System Services cron, mail, and uucp utilities</h4>
<p>[[[[ Contributing writer: Debra L Noll/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contacts: Bev Kawalski/Poughkeepsie/IBM@IBMUS,
Marna Walle/Poughkeepsie/IBM@IBMUS, Al J. Noll/Poughkeepsie/IBM@IBMUS,
Ann Totten/Poughkeepsie/IBM@IBMUS,  John Bouzakis/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13,
for each new release, certain post-installation activities
had to be done for the z/OS UNIX System Services <span class="synph"><span class="kwd">cron</span></span>, <span class="synph"><span class="kwd">mail</span></span>,
and <span class="synph"><span class="kwd">uucp</span></span> utilities in order for the root file system to be
mounted read-only. Starting in z/OS V1R13, the <samp class="xph">/usr/lib/cron</samp>, <samp class="xph">/usr/mail</samp>,
and <samp class="xph">/usr/spool</samp> directories are provided as symbolic links.
Note that this migration action does not affect other mail utilities
such as <span class="synph"><span class="kwd">tsmail</span></span>, <span class="synph"><span class="kwd">mailx</span></span>, and Communications Server <span class="synph"><span class="kwd">sendmail</span></span>.<a id="idx1313"></a></p>
<table id="wq671" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>Before the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes, if either of the following is true:


<ul>
<li>You have performed the post-installation activities to make <span class="synph"><span class="kwd">uucp</span></span>, <span class="synph"><span class="kwd">cron</span></span>,
or <span class="synph"><span class="kwd">mail </span></span> supported for a read-only z/OS root. You do not
necessarily have to be running with the z/OS root as read only but
only have the post-installation customization as described in <cite>z/OS UNIX System Services Planning</cite>.</li>
<li>You have used <span class="synph"><span class="kwd">uucp</span></span>, <span class="synph"><span class="kwd">cron</span></span>, or <span class="synph"><span class="kwd">mail </span></span> facilities
and have not performed the post-installation customization as described
in <cite>z/OS UNIX System Services Planning</cite>.</li></ul></td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or
fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>
<ul>
<li><span>Because the new z/OS V1R13 symbolic links are directed
to a system-specific file system, other file systems are not affected
by this change.</span>  When shared in read-only mode, the z/OS
root will contain the <samp class="xph">/var</samp> symbolic links.</li>
<li>If you use any of the utilities (<span class="synph"><span class="kwd">uucp</span></span>, <span class="synph"><span class="kwd">cron</span></span>,
or <span class="synph"><span class="kwd">mail </span></span>), then review any files that these utilities produce,
such as logs. Now that the symbolic links, by default, point to the <samp class="xph">/var</samp> location,
ensure that you have room for these utility-produced files in <samp class="xph">/var</samp>.
 This might mean: (1) creating a separate file system for files (such
as <samp class="xph">/var/spool</samp>, as recommended in <cite>z/OS UNIX System Services Planning</cite>),
(2) moving existing separate file systems you already have to be mounted
under <samp class="xph">/var</samp> (from<samp class="xph">/etc</samp>, for instance), or (3)
enlarging your <samp class="xph">/var</samp> file system if you don't have separately
mounted file systems for these utilities.</li></ul></td>
</tr>
<tr>
<td><strong>Related IBM Health Checker
for z/OS check</strong>:</td>
<td>Use check ZOSMIGV1R13_RO_SYMLINKS, available
with APAR <span>OA35605 and APAR OA35636.</span></td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: 
</p>
<div>
<div class="note-noindent" id="wq672">
<span class="notetitle">Note:</span> <span class="notebody">While
this migration action should be performed before the first IPL of
z/OS V1R13, the changes to use <samp class="xph">/var</samp> for this support can
be done at any time. Although previous documentation had shown the
use of <samp class="xph">/etc n</samp> examples, after further consideration, we
now recommend using <samp class="xph">/var</samp> for these utilities.</span></div></div>
<ol type="1">
<li><span>If you currently use /etc or another directory
for post-installation customization for these utilities</span>, decide
if you want to continue to use those directories or move to the /var
structure that is provided with z/OS V1R13. Moving to the /var structure
is recommended because: 


<ul>
<li>You can minimize any subsequent post-installation customization,
since the symbolic links to <samp class="xph">/var</samp> will be provided for you
by IBM.  Continued use of non-/var directories may mean post-installation
work every time to remove the delivered structure and replace it with
your own.</li>
<li>Continued use of <samp class="xph">/etc</samp> (or another directory),
requires you to manage and maintain the symbolic links required from <samp class="xph">/var</samp> to
that directory, which is &quot;double symlinking.&quot;  This &quot;double
symlinking&quot; might be confusing for those that maintain the system.</li></ul></li>
<li>If you use<samp class="xph"> /var</samp> for your post-installation
customization, then ensure that the <samp class="xph">/var</samp> file system to
be mounted at the z/OS V1R13 level of <samp class="xph">/var</samp> (or subdirectories
shown below) contains the following directories or files for the utilities
you are using.  These will now be referenced by symbolic links in
the z/OS V1R13 root file system <span>when cron, mail, and
uucp are used</span>:


<ul>
<li><samp class="xph">/var/mail</samp></li>
<li><samp class="xph">/var/spool</samp></li>
<li><samp class="xph">/var/spool/cron</samp></li>
<li><samp class="xph">/var/spool/locks</samp></li>
<li><samp class="xph">/var/spool/cron/atjobs</samp></li>
<li><samp class="xph">/var/spool/cron/crontabs</samp></li>
<li><samp class="xph">/var/spool/uucp</samp></li>
<li><samp class="xph">/var/spool/uucppublic</samp></li>
<li><samp class="xph">/var/spool/uucp/.Xqtdir</samp></li>
<li><samp class="xph">/var/spool/uucp/.Sequence</samp></li>
<li><samp class="xph">/var/spool/uucp/.Status</samp></li>
<li><samp class="xph">/var/cron</samp></li>
<li><samp class="xph">/var/uucp/Systems </samp></li>
<li><samp class="xph">/var/uucp/Devices</samp></li>
<li><samp class="xph">/var/uucp/Dialers</samp></li>
<li><samp class="xph">/var/uucp/Dialcodes</samp></li>
<li><samp class="xph">/var/uucp/Permissions</samp></li>
<li><samp class="xph">/var/uucp/config </samp></li></ul>


<p><span>Note that the <samp class="xph">/var</samp> file system
provided by ServerPac will contain these directories but not the files,
because the files are provided when the utilities are configured and
used.</span> If you use to use the ServerPac <samp class="xph">/var</samp>  and add
your files to that <samp class="xph">/var</samp> file system, that is acceptable,
as documented in <a href="e0z3m100.htm#at3gend">Migrate /etc and /var system control files</a>. This action is similar to
how you would merge an <samp class="xph">/var</samp> file system provided by Server
Pac with an existing file system.</p>


<p>If you have any user files
under <samp class="xph">/usr/spool</samp>, <samp class="xph">/usr/lib/cron</samp>, or <samp class="xph">/usr/mail</samp> in
the root file system (that is, they have not been symlinked under <samp class="xph">/var</samp> or
another directory to support the read-only root), then those
files must be moved to <samp class="xph">/var/spool,</samp> <samp class="xph">/var/cron</samp>,
or <samp class="xph">/var/mail</samp> (or another directory besides the <samp class="xph">/var</samp> that
you choose).</p></li></ol>
<p><strong>Reference information</strong>: <cite>z/OS UNIX System Services Planning</cite>.</p>
<h3 id="e0z3m100-gen153">z/OS UNIX actions to perform after the first IPL
of z/OS V2R1</h3>
<p>This topic describes z/OS UNIX migration actions that you
can perform only after you have IPLed z/OS V2R1.
You need a running z/OS V2R1
system to perform these actions.</p>
<p><a href="e0z3m100.htm#dt2mg502">Determine if any sticky bit files or external links in your
z/OS UNIX file system are involved in the invocation of MVS programs
that are link-edited with the AC=1 attribute (Part 2 after IPL of
z/OS V2R1)</a></p>
<p><a href="e0z3m100.htm#bpxuniq">Use the BPX.UNIQUE.USER profile instead of BPX.DEFAULT.USER</a></p>
<p><a href="e0z3m100.htm#invrexx">Discontinue use of invalid REXX variables in z/OS UNIX syscalls</a></p>
<h4 id="dt2mg796">Determine if any sticky bit files or external links in your
z/OS UNIX file system are involved in the invocation of MVS programs
that are link-edited with the AC=1 attribute (Part 2 after IPL of
z/OS V2R1)</h4><a id="idx1314"></a>
<p></p>
<p><strong>Description</strong>: Starting in z/OS V2R1, the invocation requirements
for MVS load library programs invoked via the z/OS UNIX spawn, exec
and attach_exec services have changed.   These changes apply to the
invocation of MVS programs link-edited AC=1 found in an APF-authorized
library and for MVS load library programs that are to run as a z/OS
UNIX set-user-id or set-group-id program.  The following list describes
the changes: 
</p>
<ul>
<li>If the z/OS UNIX <em>pathname</em> that is supplied
to spawn,  exec or attach_exec represents an external link that resolves
to an MVS program found in an APF-authorized library and link-edited
with the AC=1 attribute, the external link must have an owning UID
of 0 and not be found in a file system that is mounted as NOSECURITY
to allow this type of invocation.</li>
<li>If the z/OS UNIX <em>pathname</em>  that is supplied
to spawn, exec, or attach_exec represents a regular file with the
sticky bit attribute that resolves to an MVS program found in an APF-authorized
library and link-edited with the AC=1 attribute, the sticky bit file
must have an owning UID of 0 or have the APF extended attribute turned
on to allow this type of invocation. Additionally, the sticky bit
file must not be found in a file system that is mounted as NOSECURITY
to allow this type of invocation.</li>
<li>If the z/OS UNIX <em>pathname</em> that supplied to
spawn, exec or attach_exec represents a symbolic link to a regular
file with the sticky bit attribute and the sticky bit file has the
set-user-id attribute, the symbolic link must have an owning UID of
0 or an owning UID equal to that of the sticky bit file.  If the sticky
bit file has the set-group-id attribute, the symbolic link must have
an owning UID of 0 or an owning GID equal to that of the sticky bit
file. Additionally, the symbolic link must not be found in a file
system that is mounted as NOSECURITY to allow this type of invocation.</li></ul>
<table id="wq674" width="100%" summary="" border="1" frame="hsides" rules="rows">
<tbody valign="top">
<tr>
<td><strong>Element or feature:</strong></td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced:</strong></td>
<td>z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Applies to migration from:</strong></td>
<td>z/OS V1R13 and z/OS V1R12 without APAR OA41101
applied.</td>
</tr>
<tr>
<td><strong>Timing:</strong></td>
<td>After the first IPL of z/OS V2R1. (For steps
to take before the first IPL, see <a href="e0z3m100.htm#dt2mg499">Determine if any sticky bit files or external links in your
z/OS UNIX file system are involved with link-edited MVS programs with
AC=1 (Part 1 before the first IPL of V2R1)</a>).</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>No, but recommended even though most, if not
all, IBM and vendor products install their executable files into the
z/OS UNIX file system with an owning UID of 0, so few, if any, executable
files on a customer system should have a problem.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts:</strong></td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check:</strong></td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take after the first IPL</strong>: If you see EC6-xxxxC04A
abends occurring, look for message BPXP028I in the system log to determine
the details of the z/OS UNIX files or links and MVS programs involved
with the errors and how to correct the problem. This abend is indicative
of an attempt to execute an improperly installed z/OS UNIX sticky
bit file, symbolic link or external link that resolves to a MVS program.
 For more information about message BPXP028I, see <cite>z/OS MVS System Messages, Vol 3 (ASB-BPX),</cite>.</p>
<p>For <strong>Steps to take before the first IPL</strong>, see <a href="e0z3m100.htm#dt2mg499">Determine if any sticky bit files or external links in your
z/OS UNIX file system are involved with link-edited MVS programs with
AC=1 (Part 1 before the first IPL of V2R1)</a>.</p>
<p><strong>Reference information:</strong> .</p>
<h4 id="dt2mg797">Use the BPX.UNIQUE.USER profile instead of BPX.DEFAULT.USER</h4><a id="idx1315"></a><a id="idx1316"></a><a id="idx1317"></a><a id="idx1318"></a><a id="idx1319"></a><a id="idx1320"></a>
<p>[[[[ Contributing writer: Debra L Noll/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contact: John Helmbold/Poughkeepsie/IBM@IBMUS
]]]]</p>
<p><strong>Description</strong>:  Before z/OS V1R11,
if the BPX.DEFAULT.USER profile in the FACILITY class was defined,
users who accessed z/OS UNIX services who did not have
an OMVS user or group segment were assigned the default OMVS segments
for the length of the user session. All users of the default OMVS
segments shared the same UID and GID. As of z/OS V1R11, if BPX.UNIQUE.USER has been defined,
users who access z/OS UNIX services
who do not have an OMVS user or group segment are automatically assigned
an OMVS segment with a unique UID and GID. The new OMVS segments are
added to the user and group profiles in the RACF database.<a id="idx1321"></a><a id="idx1322"></a></p>
<table id="wq675" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V2R1. Function introduced in z/OS V1R11.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R13 and z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes because z/OS V1R13 is planned to be the
last release to support BPX.DEFAULT.USER (as previewed in z/OS
V1R13 Software Announcement 211-007, dated February 15, 2011).
IBM recommends that you either use the BPX.UNIQUE.USER support, or
assign unique UIDs to users who need them and assign GIDs for their
groups. The use of BPX.UNIQUE.USER increases security because shared
IDs are not used.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health
Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: Follow the steps in <cite>z/OS UNIX System Services Planning</cite> to
set up the BPX.UNIQUE.USER profile. If BPX.DEFAULT.USER has not been
deleted, BPX.UNIQUE.USER takes precedence when default OMVS segments
are used. This migration action is mandatory when migrating to z/OS
V2R1 from z/OS V1R12 or z/OS V1R13.</p>
<p>To remove the BPX.DEFAULT.USER profile, use the following RACF commands: </p>
<pre class="xmp"><code>RDELETE FACILITY BPX.DEFAULT.USER 
SETROPTS RACLIST(FACILITY) REFRESH</code></pre>
<p><strong>Reference information</strong>:  
</p>
<ul>
<li><cite>z/OS UNIX System Services Planning</cite></li>
<li><cite>z/OS Security Server RACF Security Administrator&amp;apos;s Guide</cite></li></ul>
<h4 id="invrexx">Discontinue use of invalid REXX variables in z/OS UNIX syscalls</h4><a id="idx1323"></a><a id="idx1324"></a><a id="idx1325"></a><a id="idx1326"></a><a id="idx1327"></a><a id="idx1328"></a>
<p>[[[[ Contributing writer: Debra L Noll/Poughkeepsie/IBM@IBMUS
]]]] [[[[ Technical contacts: Michael Cox/Poughkeepsie/IBM@IBMUS and
William Schoen/Poughkeepsie/IBM@IBMUS ]]]]</p>
<p><strong>Description</strong>: Before z/OS V1R13, issuing z/OS UNIX syscalls
with invalid REXX variables might not generate an error message. Starting
in z/OS V1R13, error messages are issued.<a id="idx1329"></a></p>
<table id="wq676" width="100%" summary="" border="1" frame="hsides" rules="rows" class="presentation" role="presentation">
<tbody valign="top">
<tr>
<td><strong>Element or feature</strong>:</td>
<td>z/OS UNIX.</td>
</tr>
<tr>
<td><strong>When change was introduced</strong>:</td>
<td>z/OS V1R13.</td>
</tr>
<tr>
<td><strong>Applies to migration from</strong>:</td>
<td>z/OS V1R12.</td>
</tr>
<tr>
<td><strong>Timing</strong>:</td>
<td>After the first IPL of z/OS V2R1.</td>
</tr>
<tr>
<td><strong>Is the migration action required?</strong></td>
<td>Yes. Using invalid REXX variables could cause
problems that might not be noticed.</td>
</tr>
<tr>
<td><strong>Target system hardware requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Target system software requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Other system (coexistence or fallback) requirements</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Restrictions</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>System impacts</strong>:</td>
<td>None.</td>
</tr>
<tr>
<td><strong>Related IBM Health Checker for z/OS check</strong>:</td>
<td>None.</td>
</tr>
</tbody>
</table>
<p><strong>Steps to take</strong>: If you have REXX programs with multiple syscalls
that use the (<span class="synph"><span class="var">rexx-variable</span></span>) format of passing
variables and do not check RETVAL and or ERRNO upon return, follow
these steps.</p>
<ol type="1">
<li>Run these programs.</li>
<li>Fix parsing errors as they occur, replacing invalid REXX variables
with valid ones. The error number will identify the invalid REXX variable.
Note that REXX variable names cannot start with a digit or include
arithmetic operators. For example, x*y is an invalid REXX variable. 

<ul>
<li>If the program produces a REXX parsing error, the error will be: 
<pre class="xmp"><code>IRX0041I Error running ....... line xx:  ......</code></pre>  

<p>This
is a TSO REXX error message.</p></li>
<li> If the program produces a z/OS UNIX syscall parsing error, the
error code will be -21,-22,..., as described under the section "Returned
from the SYSCALL environment" in the USS REXX documentation.</li></ul></li></ol>
<p><strong>Reference information</strong>: See <cite>z/OS Using REXX and z/OS UNIX System Services</cite> for
information about the error message.</p>
<h1 id="access">Appendix. Accessibility features for CSM</h1>
<p>Accessibility features help a user who has a physical disability, such
as restricted mobility or limited vision, to use information technology products
successfully.</p>
<h2 id="e0z3m100-gen154">Using assistive technologies</h2><a id="idx1330"></a>
<p>Assistive technology products, such as screen readers, function
with the user interfaces found in z/OS. Consult
the assistive technology documentation for specific information when
using such products to access z/OS interfaces.</p>
<h2 id="e0z3m100-gen155">Keyboard navigation of the user interface</h2><a id="idx1331"></a><a id="idx1332"></a><a id="idx1333"></a><a id="idx1334"></a>
<p>Users can access z/OS user interfaces using TSO/E or
ISPF. Refer to <cite>z/OS TSO/E Primer</cite>, <cite>z/OS TSO/E User&amp;apos;s Guide</cite>,
and <cite>z/OS ISPF User&amp;apos;s Guide Vol I</cite> for
information about accessing TSO/E and ISPF interfaces. These guides
describe how to use TSO/E and ISPF, including the use of keyboard
shortcuts or function keys (PF keys). Each guide includes the default
settings for the PF keys and explains how to modify their functions.<a id="idx1335"></a><a id="idx1336"></a><a id="idx1337"></a></p>
<h2 id="e0z3m100-gen156">z/OS information</h2>
<p>z/OS information is accessible
using screen readers with the Library Server versions of z/OS books in the Internet library
at:  
</p>
<pre class="xmp"><code><a href=" http://www.ibm.com/systems/z/os/zos/bkserv/">http://www.ibm.com/systems/z/os/zos/bkserv/</a></code></pre><a id="idx1338"></a><a id="idx1339"></a>
<h1 id="notice">Notices</h1><a id="idx1340"></a>
<p>This information was developed for products and services offered
in the U.S.A. or elsewhere.</p>
<p>IBM may not offer the products, services, or features discussed
in this document in other countries. Consult your local IBM representative
for information on the products and services currently available in
your area. Any reference to an IBM product, program, or service is
not intended to state or imply that only that IBM product, program,
or service may be used. Any functionally equivalent product, program,
or service that does not infringe any IBM intellectual property right
may be used instead. However, it is the user's responsibility to evaluate
and verify the operation of any non-IBM product, program, or service.</p>
<p>IBM may have patents or pending patent applications covering subject
matter described in this document. The furnishing of this document
does not give you any license to these patents. You can send license
inquiries, in writing, to: </p>
<div class="lines">IBM Director of Licensing<br />
IBM Corporation<br />
North Castle Drive<br />
Armonk, NY&nbsp;&nbsp;10504-1785<br />
U.S.A<br />
</div>
<p>For license inquiries regarding double-byte character set (DBCS)
information, contact the IBM Intellectual Property Department in your
country or send inquiries, in writing, to:</p>
<div class="lines">Intellectual Property Licensing<br />
Legal and Intellectual Property Law<br />
IBM Japan, Ltd.<br />
19-21, Nihonbashi-Hakozakicho, Chuo-ku<br />
Tokyo 103-8510, Japan <br />
</div>
<p>The following paragraph does not apply to the United Kingdom or
any other country where such provisions are inconsistent with local
law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION &quot;AS
IS&quot; WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore,
this statement may not apply to you.</p>
<p>This information could include technical inaccuracies or typographical
errors. Changes are periodically made to the information herein; these
changes will be incorporated in new editions of the publication. IBM
may make improvements and/or changes in the product(s) and/or the
program(s) described in this publication at any time without notice.</p>
<p>Any references in this information to non-IBM Web sites are provided
for convenience only and do not in any manner serve as an endorsement
of those Web sites. The materials at those Web sites are not part
of the materials for this IBM product and use of those Web sites is
at your own risk.</p>
<p>IBM may use or distribute any of the information you supply in
any way it believes appropriate without incurring any obligation to
you.</p>
<p>Licensees of this program who wish to have information about it
for the purpose of enabling: (i) the exchange of information between
independently created programs and other programs (including this
one) and (ii) the mutual use of the information which has been exchanged,
should contact:  </p>
<div class="lines">Site Counsel<br />
IBM Corporation<br />
2455 South Road<br />
Poughkeepsie, NY 12601-5400<br />
USA<br />
</div>
<p>Such information may be available, subject to appropriate terms
and conditions, including in some cases, payment of a fee.</p>
<p>The licensed program described in this information and all licensed
material available for it are provided by IBM under terms of the IBM
Customer Agreement, IBM International Program License Agreement, or
any equivalent agreement between us.</p>
<p>Information concerning non-IBM products was obtained from the suppliers
of those products, their published announcements or other publicly
available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related
to non-IBM products. Questions on the capabilities of non-IBM products
should be addressed to the suppliers of those products.</p>
<p>All statements regarding IBM's future direction or intent are subject
to change or withdrawal without notice, and represent goals and objectives
only.</p>
<p>If you are viewing this information softcopy, the photographs and
color illustrations may not appear.</p>
<h2 id="unsupphw">Policy for unsupported hardware</h2>
<div>
<p></p></div>
<p>Various z/OS elements, such as DFSMS, HCD, JES2, JES3, and MVS,
contain code that supports specific hardware servers or devices. In
some cases, this device-related element support remains in the product
even after the hardware devices pass their announced End of Service
date. z/OS may continue to service element code; however, it will
not provide service related to unsupported hardware devices. Software
problems related to these devices will not be accepted for service,
and current service activity will cease if a problem is determined
to be associated with out-of-support devices. In such cases, fixes
will not be issued.</p>
<h2 id="minimumsupportedhardware">Minimum supported hardware</h2>
<div>
<p></p></div>
<p>The minimum supported hardware for z/OS releases identified in
z/OS announcements can subsequently change when service for particular
servers or devices is withdrawn. Likewise, the levels of other software
products supported on a particular release of z/OS are subject to
the service support lifecycle of those products. Therefore, z/OS and
its product publications (for example, panels, samples, messages,
and product documentation) can include references to hardware and
software that is no longer supported.</p>
<h1 id="idg15543">Trademarks</h1>
<p>IBM, the IBM logo, and ibm.com&reg; are
trademarks or registered trademarks of International Business Machines
Corp., registered in many jurisdictions worldwide.  Other product
and service names might be trademarks of IBM or
other companies.  A current list of IBM trademarks
is available on the Web at  <a href="http://www.ibm.com/legal/copytrade.shtml" target="_blank">"Copyright and trademark information"</a>  at <a href="http://www.ibm.com/legal/copytrade.shtml" target="_blank">www.ibm.com/legal/copytrade.shtml</a>.</p>
<p>Pentium is a registered trademark of Intel Corporation in the United
States, other countries, or both. (For a complete list of Intel trademarks,
see
.)</p>
<p>Linux is a registered trademark of Linus Torvalds in the United
States, other countries, or both.</p>
<p>Microsoft, Windows, and Windows NT are registered trademarks of
Microsoft Corporation in the United States, other countries, or both</p>
<p>UNIX is a registered trademark
of The Open Group in the United States, other countries, or both.</p>
<p>Java is a registered trademark of Sun Microsystems, Inc. in the
United States, other countries, or both.</p>
<p>Other company, product, or service names may be trademarks or service
marks of others.</p>
<h1 id="wq678">Index</h1>
<a name="IDX0_00" href="#IDX1_00">Special characters</a><br />
<a name="IDX0_01" href="#IDX1_01">Numerics</a><br />
<a name="IDX0_41" href="#IDX1_41">A</a>
<a name="IDX0_42" href="#IDX1_42">B</a>
<a name="IDX0_43" href="#IDX1_43">C</a>
<a name="IDX0_44" href="#IDX1_44">D</a>
<a name="IDX0_45" href="#IDX1_45">E</a>
<a name="IDX0_46" href="#IDX1_46">F</a>
<a name="IDX0_47" href="#IDX1_47">G</a>
<a name="IDX0_48" href="#IDX1_48">H</a>
<a name="IDX0_49" href="#IDX1_49">I</a>
<a name="IDX0_4A" href="#IDX1_4A">J</a>
<a name="IDX0_4B" href="#IDX1_4B">K</a>
<a name="IDX0_4C" href="#IDX1_4C">L</a>
<a name="IDX0_4D" href="#IDX1_4D">M</a>
<a name="IDX0_4E" href="#IDX1_4E">N</a>
<a name="IDX0_4F" href="#IDX1_4F">O</a>
<a name="IDX0_50" href="#IDX1_50">P</a>
<a name="IDX0_51" href="#IDX1_51">Q</a>
<a name="IDX0_52" href="#IDX1_52">R</a>
<a name="IDX0_53" href="#IDX1_53">S</a>
<a name="IDX0_54" href="#IDX1_54">T</a>
<a name="IDX0_55" href="#IDX1_55">U</a>
<a name="IDX0_56" href="#IDX1_56">V</a>
<a name="IDX0_57" href="#IDX1_57">W</a>
<a name="IDX0_58" href="#IDX1_58">X</a>
<a name="IDX0_5A" href="#IDX1_5A">Z</a>
<hr></hr>
<strong><a name="IDX1_00" href="#IDX0_00">Special characters</a></strong>
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1055" class="indexlink">.bak file system</a>
</li>
<li><a href="e0z3m100.htm#idx123" class="indexlink">/etc directory, migrating files in</a>
</li>
<li>&lt;bogus index entry&gt;
<a href="e0z3m100.htm#idx290" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx723" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1142" class="indexlink">*S main,FLUSH</a>
</li>
<li><a href="e0z3m100.htm#idx1297" class="indexlink">/usr/sbin/mount invocations</a>
</li>
<li>/usr/sbin/unmount invocations
<a href="e0z3m100.htm#idx1298" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1312" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx124" class="indexlink">/var directory, migrating files in</a>
</li>
</ul>
<strong><a name="IDX1_01" href="#IDX0_01">Numerics</a></strong>
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx81" class="indexlink">3270 PC File Transfer Program, no migration actions for</a>
</li>
<li>3800 Printing Subsystem, preparing to use
<a href="e0z3m100.htm#idx407" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx941" class="indexlink">(2)</a>
</li>
<li>3900 Printing Subsystem, preparing to use
<a href="e0z3m100.htm#idx408" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx942" class="indexlink">(2)</a>
</li>
<li>64-bit mode
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1012" class="indexlink">DFSMS macros</a>
</li>
</ul>
</li>
<li>64-bit TMI copy buffer function
<a href="e0z3m100.htm#idx319" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx799" class="indexlink">(2)</a>
</li>
</ul>
<strong><a name="IDX1_41" href="#IDX0_41">A</a></strong>
<ul class="indexlist">
<li>accessibility
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1339" class="indexlink">screen readers</a>
</li>
</ul>
</li>
<li>ACDS (active control data set), ensuring integrity of
<a href="e0z3m100.htm#idx392" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx924" class="indexlink">(2)</a>
</li>
<li>actions to perform, meaning of
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx20" class="indexlink">after first IPL</a>
</li>
<li><a href="e0z3m100.htm#idx18" class="indexlink">before first IPL</a>
</li>
<li><a href="e0z3m100.htm#idx16" class="indexlink">before installing</a>
</li>
</ul>
</li>
<li>active control data set (ACDS), ensuring integrity of
<a href="e0z3m100.htm#idx393" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx925" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx828" class="indexlink">additional parameter</a>
</li>
<li>address space
<a href="e0z3m100.htm#idx285" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx715" class="indexlink">(2)</a>
</li>
<li>after first IPL, migration actions
<ul class="indexlist">
<li>BCP
<a href="e0z3m100.htm#idx298" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx758" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx766" class="indexlink">(3)</a>
</li>
<li>Communications Server
<a href="e0z3m100.htm#idx354" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx874" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx377" class="indexlink">Cryptographic Services</a>
</li>
<li>DFSMS
<a href="e0z3m100.htm#idx422" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1008" class="indexlink">(2)</a>
</li>
<li>DFSORT
<a href="e0z3m100.htm#idx439" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1028" class="indexlink">(2)</a>
</li>
<li>Distributed File Service
<a href="e0z3m100.htm#idx466" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1067" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1098" class="indexlink">Infoprint Server</a>
</li>
<li>JES2
<a href="e0z3m100.htm#idx487" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1113" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1163" class="indexlink">Language Environment</a>
</li>
<li>RMF
<a href="e0z3m100.htm#idx535" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1194" class="indexlink">(2)</a>
</li>
<li>SDSF
<a href="e0z3m100.htm#idx557" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1218" class="indexlink">(2)</a>
</li>
<li>Security Server
<a href="e0z3m100.htm#idx587" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1258" class="indexlink">(2)</a>
</li>
<li>sysplex
<a href="e0z3m100.htm#idx249" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx667" class="indexlink">(2)</a>
</li>
<li>XL C/C++
<a href="e0z3m100.htm#idx612" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1277" class="indexlink">(2)</a>
</li>
<li>z/OS UNIX
<a href="e0z3m100.htm#idx645" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1317" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx1325" class="indexlink">(3)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx909" class="indexlink">after first IPL, migration actions, Cryptographic Services</a>
</li>
<li>after the first IPL, migration actions
<ul class="indexlist">
<li>z/OS Font Collection
<a href="e0z3m100.htm#idx620" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1285" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>AIRSHREP.sh
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx750" class="indexlink">Predictive Failure Analysis (PFA)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx754" class="indexlink">ALLOWCMD(Y) keyword</a>
</li>
<li><a href="e0z3m100.htm#idx55" class="indexlink">Alternate Library for REXX, no migration actions for</a>
</li>
<li><a href="e0z3m100.htm#idx815" class="indexlink">ancillary input queue (AIQ)</a>
</li>
<li><a href="e0z3m100.htm#idx1102" class="indexlink">aopsetup, running</a>
</li>
<li>AR mode
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1013" class="indexlink">DFSMS macros</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx210" class="indexlink">ARCH(8) compiler option</a>
</li>
<li>ARRCAT
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx998" class="indexlink">resource contention, when starting CDS backup</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx1330" class="indexlink">assistive technologies</a>
</li>
<li>AT-TLS access to CSFIQA and CSFRNG resources
<a href="e0z3m100.htm#idx332" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx846" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx867" class="indexlink">(3)</a>
</li>
<li><a href="e0z3m100.htm#idx822" class="indexlink">attack detection</a>
</li>
<li>AUTHCMD and AUTHPGM NAMES section of your IKJTSOxx member
<a href="e0z3m100.htm#idx310" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx790" class="indexlink">(2)</a>
</li>
<li>Auto-reply for WTORs
<a href="e0z3m100.htm#idx294" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx724" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1143" class="indexlink">Automatic flush</a>
</li>
<li>automation
<a href="e0z3m100.htm#idx343" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx857" class="indexlink">(2)</a>
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx730" class="indexlink">CSVLLAxx member</a>
</li>
<li>D TCPIP,tnproc,&lt;Telnet&gt;,CONN command
<a href="e0z3m100.htm#idx335" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx849" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx729" class="indexlink">library lookaside (LLA)</a>
</li>
</ul>
</li>
</ul>
<strong><a name="IDX1_42" href="#IDX0_42">B</a></strong>
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1080" class="indexlink">basic mode to extended mode, IP PrintWay migration from</a>
</li>
<li>BCP migration actions
<ul class="indexlist">
<li>after first IPL
<a href="e0z3m100.htm#idx296" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx756" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx764" class="indexlink">(3)</a>
</li>
<li>before first IPL
<a href="e0z3m100.htm#idx277" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx707" class="indexlink">(2)</a>
</li>
<li>before installing
<a href="e0z3m100.htm#idx256" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx674" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>BCPii API calls
<a href="e0z3m100.htm#idx261" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx679" class="indexlink">(2)</a>
</li>
<li>BCPii ENF exits
<a href="e0z3m100.htm#idx262" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx680" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx56" class="indexlink">BDT, no migration actions for</a>
</li>
<li><a href="e0z3m100.htm#idx57" class="indexlink">BDT File-to-File, no migration actions for</a>
</li>
<li><a href="e0z3m100.htm#idx58" class="indexlink">BDT SNA NJE, no migration actions for</a>
</li>
<li><a href="e0z3m100.htm#idx1146" class="indexlink">before first IPL</a>
</li>
<li>before first IPL, migration actions
<ul class="indexlist">
<li>BCP
<a href="e0z3m100.htm#idx279" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx709" class="indexlink">(2)</a>
</li>
<li>Communications Server
<a href="e0z3m100.htm#idx338" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx852" class="indexlink">(2)</a>
</li>
<li>Cryptographic Services
<a href="e0z3m100.htm#idx363" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx887" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx895" class="indexlink">(3)</a>
</li>
<li>DFSMS
<a href="e0z3m100.htm#idx401" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx935" class="indexlink">(2)</a>
</li>
<li>DFSORT
<a href="e0z3m100.htm#idx433" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1022" class="indexlink">(2)</a>
</li>
<li>Distributed File Service
<a href="e0z3m100.htm#idx457" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1042" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx111" class="indexlink">general</a>
</li>
<li><a href="e0z3m100.htm#idx1084" class="indexlink">Infoprint Server</a>
</li>
<li>JES3
<a href="e0z3m100.htm#idx502" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1130" class="indexlink">(2)</a>
</li>
<li>Library Server
<a href="e0z3m100.htm#idx513" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1170" class="indexlink">(2)</a>
</li>
<li>RMF
<a href="e0z3m100.htm#idx522" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1179" class="indexlink">(2)</a>
</li>
<li>SDSF
<a href="e0z3m100.htm#idx548" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1209" class="indexlink">(2)</a>
</li>
<li>Security Server
<a href="e0z3m100.htm#idx571" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1242" class="indexlink">(2)</a>
</li>
<li>sysplex
<a href="e0z3m100.htm#idx242" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx660" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx606" class="indexlink">XL C/C++</a>
</li>
<li>z/OS UNIX
<a href="e0z3m100.htm#idx634" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1304" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>before installing, migration actions
<ul class="indexlist">
<li>BCP
<a href="e0z3m100.htm#idx258" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx676" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx883" class="indexlink">Cryptographic Services</a>
</li>
<li>DFSMS
<a href="e0z3m100.htm#idx384" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx916" class="indexlink">(2)</a>
</li>
<li>Distributed File Service
<a href="e0z3m100.htm#idx453" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1050" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx87" class="indexlink">general</a>
</li>
<li>Infoprint Server
<a href="e0z3m100.htm#idx475" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1076" class="indexlink">(2)</a>
</li>
<li>JES2
<a href="e0z3m100.htm#idx480" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1106" class="indexlink">(2)</a>
</li>
<li>JES3
<a href="e0z3m100.htm#idx498" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1126" class="indexlink">(2)</a>
</li>
<li>Security Server
<a href="e0z3m100.htm#idx566" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1234" class="indexlink">(2)</a>
</li>
<li>sysplex
<a href="e0z3m100.htm#idx237" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx655" class="indexlink">(2)</a>
</li>
<li>XL C/C++
<a href="e0z3m100.htm#idx602" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1273" class="indexlink">(2)</a>
</li>
<li>z/OS Font Collection
<a href="e0z3m100.htm#idx616" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1281" class="indexlink">(2)</a>
</li>
<li>z/OS UNIX
<a href="e0z3m100.htm#idx627" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1292" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>before the first IPL, migration actions
<ul class="indexlist">
<li>z/OS Font Collection
<a href="e0z3m100.htm#idx617" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1282" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>BIND 9.2.0
<ul class="indexlist">
<li>before first IPL
<a href="e0z3m100.htm#idx324" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx833" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>BIND 9.2.0 name server
<a href="e0z3m100.htm#idx326" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx835" class="indexlink">(2)</a>
</li>
<li>BIND jobs, OAM DB2
<a href="e0z3m100.htm#idx418" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1001" class="indexlink">(2)</a>
</li>
<li>BookManager BUILD, support for
<a href="e0z3m100.htm#idx305" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx471" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx782" class="indexlink">(3)</a>, <a href="e0z3m100.htm#idx1072" class="indexlink">(4)</a>
</li>
<li><a href="e0z3m100.htm#idx59" class="indexlink">BookManager READ, no migration actions for</a>
</li>
<li>books
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx35" class="indexlink">related</a>
</li>
</ul>
</li>
<li>BPX.DEFAULT.USER profile replaced by BPX.UNIQUE.USER
<a href="e0z3m100.htm#idx650" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1322" class="indexlink">(2)</a>
</li>
<li>BPX.UNIQUE.USER profile
<a href="e0z3m100.htm#idx649" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1321" class="indexlink">(2)</a>
</li>
<li>BRODCAST parameter
<a href="e0z3m100.htm#idx491" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1117" class="indexlink">(2)</a>
</li>
</ul>
<strong><a name="IDX1_43" href="#IDX0_43">C</a></strong>
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx97" class="indexlink">capacity evaluation with zSoftCap</a>
</li>
<li><a href="e0z3m100.htm#idx213" class="indexlink">Capacity Provisioning</a>
</li>
<li>Capacity Provisioning Control Center
<a href="e0z3m100.htm#idx303" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx699" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx763" class="indexlink">(3)</a>, <a href="e0z3m100.htm#idx776" class="indexlink">(4)</a>
</li>
<li><a href="e0z3m100.htm#idx955" class="indexlink">Catalog Search Interface (CSI)</a>
</li>
<li>CBRSMR1D
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1004" class="indexlink">migration job for DFSMSdfp OAM.</a>
</li>
</ul>
</li>
<li>CDT (class descriptor table) names, RACF
<a href="e0z3m100.htm#idx580" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1251" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1160" class="indexlink">CEEPRMxx parmlib</a>
</li>
<li><a href="e0z3m100.htm#idx1153" class="indexlink">CEERCOPT sample</a>
</li>
<li><a href="e0z3m100.htm#idx1152" class="indexlink">CEERDOPT sample</a>
</li>
<li><a href="e0z3m100.htm#idx1154" class="indexlink">CELQRDOP sample</a>
</li>
<li>CFCC (coupling facility control code)
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx225" class="indexlink">levels</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx226" class="indexlink">CFRM policy, updating</a>
</li>
<li><a href="e0z3m100.htm#idx995" class="indexlink">chain rebuild (DFSMShsm), removal of patch preventing SMS MVT</a>
</li>
<li><a href="e0z3m100.htm#idx49" class="indexlink">checks, migration health</a>
</li>
<li>CHOWN.UNRESTRICTED profile in the RACF UNIXPRIV class
<a href="e0z3m100.htm#idx581" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1252" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1148" class="indexlink">CICS system definition file for Language Environment, updating</a>
</li>
<li><a href="e0z3m100.htm#idx785" class="indexlink">CIM Client for Java Version 2</a>
</li>
<li>class descriptor table (CDT) names, RACF
<a href="e0z3m100.htm#idx579" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1250" class="indexlink">(2)</a>
</li>
<li>class name conflicts, RACF
<a href="e0z3m100.htm#idx576" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1247" class="indexlink">(2)</a>
</li>
<li>CLEANUP_TIMEOUT
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx746" class="indexlink">default change</a>
</li>
</ul>
</li>
<li>clone function, zFS
<a href="e0z3m100.htm#idx461" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1046" class="indexlink">(2)</a>
</li>
<li>CMDS ABEND command
<a href="e0z3m100.htm#idx733" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx770" class="indexlink">(2)</a>
</li>
<li>CMDS FORCE command
<a href="e0z3m100.htm#idx734" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx771" class="indexlink">(2)</a>
</li>
<li>coexistence
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx14" class="indexlink">definition of</a>
</li>
</ul>
</li>
<li>COMMDS (common communications data set), ensuring integrity of
<a href="e0z3m100.htm#idx394" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx926" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx739" class="indexlink">COMMNDxx</a>
</li>
<li>common communications data set (COMMDS), ensuring integrity of
<a href="e0z3m100.htm#idx395" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx927" class="indexlink">(2)</a>
</li>
<li>Communications Server, AT-TLS access to CSFIQA and CSFRNG resources
<a href="e0z3m100.htm#idx331" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx845" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx866" class="indexlink">(3)</a>
</li>
<li>Communications Server, GATEWAY statements replaced by BEGINROUTES statements
<a href="e0z3m100.htm#idx323" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx803" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx910" class="indexlink">(3)</a>
</li>
<li>Communications Server, ICLI component
<a href="e0z3m100.htm#idx328" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx640" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx842" class="indexlink">(3)</a>, <a href="e0z3m100.htm#idx1310" class="indexlink">(4)</a>
</li>
<li>Communications Server, Netstat enhancements
<a href="e0z3m100.htm#idx351" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx865" class="indexlink">(2)</a>
</li>
<li>Communications Server migration actions
<ul class="indexlist">
<li>after first IPL
<a href="e0z3m100.htm#idx352" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx872" class="indexlink">(2)</a>
</li>
<li>before first IPL
<a href="e0z3m100.htm#idx325" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx336" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx342" class="indexlink">(3)</a>, <a href="e0z3m100.htm#idx346" class="indexlink">(4)</a>, <a href="e0z3m100.htm#idx834" class="indexlink">(5)</a>, <a href="e0z3m100.htm#idx850" class="indexlink">(6)</a>, <a href="e0z3m100.htm#idx856" class="indexlink">(7)</a>, <a href="e0z3m100.htm#idx860" class="indexlink">(8)</a>
</li>
<li>before installing
<a href="e0z3m100.htm#idx307" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx312" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx315" class="indexlink">(3)</a>, <a href="e0z3m100.htm#idx787" class="indexlink">(4)</a>, <a href="e0z3m100.htm#idx792" class="indexlink">(5)</a>, <a href="e0z3m100.htm#idx795" class="indexlink">(6)</a>
</li>
<li><a href="e0z3m100.htm#idx808" class="indexlink">Before installing</a>
</li>
<li>before the first IPL
<a href="e0z3m100.htm#idx334" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx848" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx60" class="indexlink">Communications Server Security Level 3, no migration actions for</a>
</li>
<li>CON=
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx736" class="indexlink">default changes</a>
</li>
</ul>
</li>
<li>Connection Manager
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1300" class="indexlink">migration action</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx751" class="indexlink">console commands and problem determination</a>
</li>
<li>console name modification
<a href="e0z3m100.htm#idx561" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1222" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx753" class="indexlink">CONSOLxx</a>
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx693" class="indexlink">INIT, DEFAULT, HARDCOPY and CONSOLE keyword statements require blank delimiter.</a>
</li>
</ul>
</li>
<li>control data sets, migrating SMS
<a href="e0z3m100.htm#idx387" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx919" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx11" class="indexlink">conventions used in this document</a>
</li>
<li><a href="e0z3m100.htm#idx1016" class="indexlink">COPYVOLID</a>
</li>
<li>core image of DFSMSdss Stand-Alone Services, building
<a href="e0z3m100.htm#idx412" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx953" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx224" class="indexlink">coupling facility control code (CFCC) levels</a>
</li>
<li>CPCC
<a href="e0z3m100.htm#idx698" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx775" class="indexlink">(2)</a>
</li>
<li>CPCC, Windows-based
<a href="e0z3m100.htm#idx302" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx762" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx98" class="indexlink">CPU evaluation with zSoftCap</a>
</li>
<li>CPUs, maximum number supported
<a href="e0z3m100.htm#idx276" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx706" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx907" class="indexlink">Cryptographic Services, CSFIQA resource of the CSFSERV class</a>
</li>
<li>Cryptographic Services migration actions
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx375" class="indexlink">after first IPL</a>
</li>
<li>before first IPL
<a href="e0z3m100.htm#idx361" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx885" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx893" class="indexlink">(3)</a>
</li>
<li><a href="e0z3m100.htm#idx881" class="indexlink">before installing</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx839" class="indexlink">CSA shortage</a>
</li>
<li><a href="e0z3m100.htm#idx1149" class="indexlink">CSD (CICS system definition) file for Language Environment, updating</a>
</li>
<li><a href="e0z3m100.htm#idx819" class="indexlink">CSFPDVK and CSFPDMK</a>
</li>
<li><a href="e0z3m100.htm#idx956" class="indexlink">CSI (Catalog Search Interface)</a>
</li>
<li><a href="e0z3m100.htm#idx837" class="indexlink">CSM buffer</a>
</li>
<li>CSVLLAxx member
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx728" class="indexlink">automation</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx107" class="indexlink">CustomPak Installation Dialog</a>
</li>
</ul>
<strong><a name="IDX1_44" href="#IDX0_44">D</a></strong>
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx950" class="indexlink">DADSM pre- and post-processing</a>
</li>
<li><a href="e0z3m100.htm#idx105" class="indexlink">DASD for z/OS root</a>
</li>
<li>DASD requirements
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx692" class="indexlink">Predictive Failure Analysis (PFA)</a>
</li>
</ul>
</li>
<li>data integrity of SMS control data sets
<a href="e0z3m100.htm#idx388" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx920" class="indexlink">(2)</a>
</li>
<li>data set recovery
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx967" class="indexlink">fast replication, using</a>
</li>
</ul>
</li>
<li>data sets
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx153" class="indexlink">deleted</a>
</li>
<li><a href="e0z3m100.htm#idx156" class="indexlink">new</a>
</li>
</ul>
</li>
<li>database templates, updating RACF
<a href="e0z3m100.htm#idx592" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1263" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1141" class="indexlink">DATINPTR (IATYDAT)</a>
</li>
<li><a href="e0z3m100.htm#idx1140" class="indexlink">DATLOREC</a>
</li>
<li>DB2 BIND jobs, OAM
<a href="e0z3m100.htm#idx419" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1002" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1060" class="indexlink">DCE/DFS</a>
</li>
<li>default changes
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx957" class="indexlink">Catalog Search Interface (CSI)</a>
</li>
<li><a href="e0z3m100.htm#idx747" class="indexlink">CLEANUP_TIMEOUT parameter of the automatic restart management (ARM)</a>
</li>
<li><a href="e0z3m100.htm#idx735" class="indexlink">CON=</a>
</li>
<li><a href="e0z3m100.htm#idx972" class="indexlink">DATASETRECOVERY parameter</a>
</li>
<li><a href="e0z3m100.htm#idx963" class="indexlink">PDA trace</a>
</li>
</ul>
</li>
<li>defaults DFSORT
<a href="e0z3m100.htm#idx445" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx449" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx1034" class="indexlink">(3)</a>, <a href="e0z3m100.htm#idx1038" class="indexlink">(4)</a>
</li>
<li>Define the RACF definitions to enable the GPMSERVE Started Task for Authorization Code zero (AC=0)
<a href="e0z3m100.htm#idx532" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1189" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx151" class="indexlink">deleted data sets and paths</a>
</li>
<li><a href="e0z3m100.htm#idx22" class="indexlink">description, meaning of</a>
</li>
<li>devices
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx221" class="indexlink">attaching new</a>
</li>
<li><a href="e0z3m100.htm#idx220" class="indexlink">removing unsupported</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx1227" class="indexlink">devices on the SDSF PUN panel</a>
</li>
<li><a href="e0z3m100.htm#idx1228" class="indexlink">devices on the SDSF RDR panel</a>
</li>
<li><a href="e0z3m100.htm#idx1059" class="indexlink">DFS client (DFSCM)</a>
</li>
<li>DFSMS, removing SMA fields from the SMS storage group construct IGDSGD
<a href="e0z3m100.htm#idx398" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx932" class="indexlink">(2)</a>
</li>
<li>DFSMS migration actions
<ul class="indexlist">
<li>after first IPL
<a href="e0z3m100.htm#idx420" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1006" class="indexlink">(2)</a>
</li>
<li>before first IPL
<a href="e0z3m100.htm#idx399" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx933" class="indexlink">(2)</a>
</li>
<li>before installing
<a href="e0z3m100.htm#idx382" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx914" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>DFSMSdfp IEBCOPY
<ul class="indexlist">
<li>examining and updating program calls to
<a href="e0z3m100.htm#idx411" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx945" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>DFSMSdfp OAM.
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1005" class="indexlink">OAM configuration database migration job (CBRSMR1D)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx1017" class="indexlink">DFSMSdss, COPYVOLID</a>
</li>
<li>DFSMShsm
<a href="e0z3m100.htm#idx964" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx973" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx980" class="indexlink">(3)</a>
<ul class="indexlist">
<li>applications that depend on the LIST DUMPCLASS command, updating
<a href="e0z3m100.htm#idx414" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx958" class="indexlink">(2)</a>
</li>
<li>CDS backup
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx997" class="indexlink">resource contention, ARCCAT</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx965" class="indexlink">data set recovery</a>
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx966" class="indexlink">fast replication, using</a>
</li>
</ul>
</li>
<li>messages
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx981" class="indexlink">ARC0036I (E)</a>
</li>
<li><a href="e0z3m100.htm#idx982" class="indexlink">ARC0503I (E)</a>
</li>
<li><a href="e0z3m100.htm#idx983" class="indexlink">ARC0704I (E)</a>
</li>
<li><a href="e0z3m100.htm#idx975" class="indexlink">ARC1809I</a>
</li>
</ul>
</li>
<li>messages, changed type
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx984" class="indexlink">ARC0036</a>
</li>
<li><a href="e0z3m100.htm#idx985" class="indexlink">ARC0503</a>
</li>
<li><a href="e0z3m100.htm#idx986" class="indexlink">ARC0704</a>
</li>
</ul>
</li>
<li>new default behavior for full-volume and track restore with VTOC
<a href="e0z3m100.htm#idx427" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1014" class="indexlink">(2)</a>
</li>
<li>PDA trace
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx960" class="indexlink">at startup</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx974" class="indexlink">tuning</a>
</li>
</ul>
</li>
<li>DFSMShsm, changes to CDC records, backup data set name format, migrated data sets
<a href="e0z3m100.htm#idx429" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1018" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx989" class="indexlink">DFSMShsm: Removal of the patch preventing the SMS MVT chain rebuild</a>
</li>
<li>DFSORT EXPOLD=MAX and EXPRES=0
<a href="e0z3m100.htm#idx446" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1035" class="indexlink">(2)</a>
</li>
<li>DFSORT migration actions
<ul class="indexlist">
<li>after first IPL
<a href="e0z3m100.htm#idx437" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1026" class="indexlink">(2)</a>
</li>
<li>before first IPL
<a href="e0z3m100.htm#idx431" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1020" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>DFSORT TUNE=OLD
<a href="e0z3m100.htm#idx443" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1032" class="indexlink">(2)</a>
</li>
<li>Distributed File Service migration actions
<ul class="indexlist">
<li>after first IPL
<a href="e0z3m100.htm#idx464" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1065" class="indexlink">(2)</a>
</li>
<li>before first IPL
<a href="e0z3m100.htm#idx455" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1040" class="indexlink">(2)</a>
</li>
<li>before installing
<a href="e0z3m100.htm#idx451" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1048" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>distributed identify filter
<a href="e0z3m100.htm#idx582" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx595" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx1237" class="indexlink">(3)</a>, <a href="e0z3m100.htm#idx1253" class="indexlink">(4)</a>, <a href="e0z3m100.htm#idx1266" class="indexlink">(5)</a>
</li>
<li>DLLs (dynamic link libraries) with Language Environment
<a href="e0z3m100.htm#idx406" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx940" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1139" class="indexlink">DLOG, JES3</a>
</li>
<li>document, this
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx9" class="indexlink">conventions and terminology in</a>
</li>
<li><a href="e0z3m100.htm#idx5" class="indexlink">how organized</a>
</li>
<li><a href="e0z3m100.htm#idx8" class="indexlink">how to use</a>
</li>
<li><a href="e0z3m100.htm#idx2" class="indexlink">who should read</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx33" class="indexlink">documents, related</a>
</li>
<li>Downgrade the SYSDSN ENQ
<a href="e0z3m100.htm#idx283" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx713" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx840" class="indexlink">DSPNAME and VTAM, Communications Server</a>
</li>
<li><a href="e0z3m100.htm#idx831" class="indexlink">DSPNAME for TCP/IP, Communications Server</a>
</li>
<li>dump, reassembling stand-alone
<a href="e0z3m100.htm#idx272" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx702" class="indexlink">(2)</a>
</li>
<li>dump data sets, stand-alone
<a href="e0z3m100.htm#idx254" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx672" class="indexlink">(2)</a>
</li>
<li>duplicate class names, RACF
<a href="e0z3m100.htm#idx577" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1248" class="indexlink">(2)</a>
</li>
<li>dynamic link libraries with Language Environment
<a href="e0z3m100.htm#idx405" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx939" class="indexlink">(2)</a>
</li>
</ul>
<strong><a name="IDX1_45" href="#IDX0_45">E</a></strong>
<ul class="indexlist">
<li>EEPLEVENTSPECIFICINFO in control block IXLYEEPL
<a href="e0z3m100.htm#idx264" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx682" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx43" class="indexlink">Enhanced PSP Tool</a>
</li>
<li><a href="e0z3m100.htm#idx814" class="indexlink">Enterprise Extender (EE) traffic and QDIO inbound workload queueing</a>
</li>
<li>environment variable
<ul class="indexlist">
<li>OMPROUTE_OPTIONS
<a href="e0z3m100.htm#idx347" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx861" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx44" class="indexlink">EPSPT</a>
</li>
<li><a href="e0z3m100.htm#idx1190" class="indexlink">ERB812I</a>
</li>
<li><a href="e0z3m100.htm#idx1191" class="indexlink">ERB813I</a>
</li>
<li><a href="e0z3m100.htm#idx61" class="indexlink">EREP, no migration actions for</a>
</li>
<li><a href="e0z3m100.htm#idx62" class="indexlink">ESCON Director Support, no migration actions for</a>
</li>
<li>ESQA
<a href="e0z3m100.htm#idx291" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx720" class="indexlink">(2)</a>
</li>
<li>everyone, migration actions for
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx112" class="indexlink">before first IPL</a>
</li>
<li><a href="e0z3m100.htm#idx85" class="indexlink">before installing</a>
</li>
</ul>
</li>
<li>exit routines
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx824" class="indexlink">FTCHKPWD</a>
</li>
<li><a href="e0z3m100.htm#idx1094" class="indexlink">IEFUSI</a>
</li>
<li>IGGPOST0
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx948" class="indexlink">update operator procedures for</a>
</li>
</ul>
</li>
<li>IGGPRE00
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx946" class="indexlink">update operator procedures for</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx1089" class="indexlink">Infoprint Server</a>
</li>
<li><a href="e0z3m100.htm#idx130" class="indexlink">migrating</a>
</li>
<li>SDSF
<a href="e0z3m100.htm#idx552" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1213" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx13" class="indexlink">exploitation, definition of</a>
</li>
<li>EXPOLD=OLD, DFSORT
<a href="e0z3m100.htm#idx447" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1036" class="indexlink">(2)</a>
</li>
<li>EXPRES=0 DFSORT
<a href="e0z3m100.htm#idx448" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1037" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1081" class="indexlink">extended mode, IP PrintWay migration from basic mode to</a>
</li>
</ul>
<strong><a name="IDX1_46" href="#IDX0_46">F</a></strong>
<ul class="indexlist">
<li>FACILITY class, RACF
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx138" class="indexlink">defining new profiles</a>
</li>
<li>OCSF profiles
<a href="e0z3m100.htm#idx368" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx900" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>fallback
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx15" class="indexlink">definition of</a>
</li>
</ul>
</li>
<li>fast replication
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx969" class="indexlink">using</a>
</li>
</ul>
</li>
<li>features, hardware
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx203" class="indexlink">software support of z10</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx63" class="indexlink">FFST, no migration actions for</a>
</li>
<li>FIPS 140-2 mode
<a href="e0z3m100.htm#idx370" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx902" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx817" class="indexlink">FIPS mode</a>
</li>
<li>first IPL, migration actions after
<ul class="indexlist">
<li>BCP
<a href="e0z3m100.htm#idx299" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx759" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx767" class="indexlink">(3)</a>
</li>
<li>Communications Server
<a href="e0z3m100.htm#idx355" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx875" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx378" class="indexlink">Cryptographic Services</a>
</li>
<li>DFSMS
<a href="e0z3m100.htm#idx423" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1009" class="indexlink">(2)</a>
</li>
<li>DFSORT
<a href="e0z3m100.htm#idx440" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1029" class="indexlink">(2)</a>
</li>
<li>Distributed File Service
<a href="e0z3m100.htm#idx467" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1068" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1099" class="indexlink">Infoprint Server</a>
</li>
<li>JES2
<a href="e0z3m100.htm#idx488" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1114" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1164" class="indexlink">Language Environment</a>
</li>
<li>RMF
<a href="e0z3m100.htm#idx536" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1195" class="indexlink">(2)</a>
</li>
<li>SDSF
<a href="e0z3m100.htm#idx558" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1219" class="indexlink">(2)</a>
</li>
<li>Security Server
<a href="e0z3m100.htm#idx588" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1259" class="indexlink">(2)</a>
</li>
<li>sysplex
<a href="e0z3m100.htm#idx250" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx668" class="indexlink">(2)</a>
</li>
<li>XL C/C++
<a href="e0z3m100.htm#idx613" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1278" class="indexlink">(2)</a>
</li>
<li>z/OS UNIX
<a href="e0z3m100.htm#idx646" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1318" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx1326" class="indexlink">(3)</a>
</li>
</ul>
</li>
<li>first IPL, migration actions before
<ul class="indexlist">
<li>BCP
<a href="e0z3m100.htm#idx280" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx710" class="indexlink">(2)</a>
</li>
<li>Communications Server
<a href="e0z3m100.htm#idx339" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx853" class="indexlink">(2)</a>
</li>
<li>Cryptographic Services
<a href="e0z3m100.htm#idx364" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx888" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx896" class="indexlink">(3)</a>
</li>
<li>DFSMS
<a href="e0z3m100.htm#idx402" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx936" class="indexlink">(2)</a>
</li>
<li>DFSORT
<a href="e0z3m100.htm#idx434" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1023" class="indexlink">(2)</a>
</li>
<li>Distributed File Service
<a href="e0z3m100.htm#idx458" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1043" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx113" class="indexlink">general</a>
</li>
<li><a href="e0z3m100.htm#idx1085" class="indexlink">Infoprint Server</a>
</li>
<li>JES3
<a href="e0z3m100.htm#idx503" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1131" class="indexlink">(2)</a>
</li>
<li>Library Server
<a href="e0z3m100.htm#idx514" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1171" class="indexlink">(2)</a>
</li>
<li>RMF
<a href="e0z3m100.htm#idx523" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1180" class="indexlink">(2)</a>
</li>
<li>SDSF
<a href="e0z3m100.htm#idx549" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1210" class="indexlink">(2)</a>
</li>
<li>Security Server
<a href="e0z3m100.htm#idx572" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1243" class="indexlink">(2)</a>
</li>
<li>sysplex
<a href="e0z3m100.htm#idx243" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx661" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx607" class="indexlink">XL C/C++</a>
</li>
<li>z/OS UNIX
<a href="e0z3m100.htm#idx635" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1305" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>Fix Category
<a href="e0z3m100.htm#idx180" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx195" class="indexlink">(2)</a>
</li>
<li>FIXCAT
<a href="e0z3m100.htm#idx45" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx179" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx194" class="indexlink">(3)</a>
</li>
<li>flags
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx696" class="indexlink">S99DSABA and S99ACUCB</a>
</li>
</ul>
</li>
<li>Flash Express
<a href="e0z3m100.htm#idx293" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx722" class="indexlink">(2)</a>
</li>
<li>FlashCopy
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx968" class="indexlink">fast replication, using</a>
</li>
</ul>
</li>
<li>fonts, z/OS Font Collection
<a href="e0z3m100.htm#idx619" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1284" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx970" class="indexlink">FRRECOV</a>
</li>
<li><a href="e0z3m100.htm#idx827" class="indexlink">FTCHKPWD exit routine</a>
</li>
<li>FTP
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx810" class="indexlink">FTP daemon console messages</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx809" class="indexlink">FTP daemon console messages</a>
</li>
<li>FTP password and Communication Server
<a href="e0z3m100.htm#idx317" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx797" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx826" class="indexlink">FTP user exit routine FTCHKPWD</a>
</li>
</ul>
<strong><a name="IDX1_47" href="#IDX0_47">G</a></strong>
<ul class="indexlist">
<li>GATEWAY statements replaced by BEGINROUTES statements
<a href="e0z3m100.htm#idx322" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx802" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx64" class="indexlink">GDDM, no migration actions for</a>
</li>
<li><a href="e0z3m100.htm#idx65" class="indexlink">GDDM-PGF, no migration actions for</a>
</li>
<li><a href="e0z3m100.htm#idx66" class="indexlink">GDDM-REXX, no migration actions for</a>
</li>
<li>general migration actions
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx109" class="indexlink">before first IPL</a>
</li>
<li><a href="e0z3m100.htm#idx84" class="indexlink">before installing</a>
</li>
</ul>
</li>
<li>Generic Tracker
<a href="e0z3m100.htm#idx260" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx678" class="indexlink">(2)</a>
</li>
<li>GetProfile request of the TCP/IP callable network management interface (NMI)
<a href="e0z3m100.htm#idx320" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx800" class="indexlink">(2)</a>
</li>
<li>GPMSERVE and GPM4CIM options for TCP/IP address regular expressions
<a href="e0z3m100.htm#idx530" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1187" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx769" class="indexlink">GRS</a>
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx779" class="indexlink">GRSCNFxx parmlib member</a>
</li>
</ul>
</li>
<li>GRSCNFxx parmlib member
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx778" class="indexlink">AUTHQLVL parameter</a>
</li>
</ul>
</li>
</ul>
<strong><a name="IDX1_48" href="#IDX0_48">H</a></strong>
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx160" class="indexlink">hardware migration actions</a>
</li>
<li><a href="e0z3m100.htm#idx218" class="indexlink">hardware no longer supported</a>
</li>
<li><a href="e0z3m100.htm#idx67" class="indexlink">HCD, no migration actions for</a>
</li>
<li><a href="e0z3m100.htm#idx68" class="indexlink">HCM, no migration actions for</a>
</li>
<li><a href="e0z3m100.htm#idx48" class="indexlink">health checks, migration</a>
</li>
<li><a href="e0z3m100.htm#idx150" class="indexlink">health checks, updating</a>
</li>
<li>HFS to zFS, migrating file system from
<a href="e0z3m100.htm#idx622" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1287" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx212" class="indexlink">HiperDispatch</a>
</li>
<li><a href="e0z3m100.htm#idx737" class="indexlink">HIPERDISPATCH=YES, default</a>
</li>
<li><a href="e0z3m100.htm#idx69" class="indexlink">HLASM Toolkit, no migration actions for</a>
</li>
<li>HOLDDATA
<a href="e0z3m100.htm#idx181" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx196" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx4" class="indexlink">how this document is organized</a>
</li>
<li><a href="e0z3m100.htm#idx6" class="indexlink">how to use this document</a>
</li>
</ul>
<strong><a name="IDX1_49" href="#IDX0_49">I</a></strong>
<ul class="indexlist">
<li>IBM Configuration Assistant for z/OS Communications Server
<a href="e0z3m100.htm#idx308" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx788" class="indexlink">(2)</a>
</li>
<li>IBM Health Checker, automatic start-up
<a href="e0z3m100.htm#idx275" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx705" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx30" class="indexlink">IBM Health Checker related check, meaning of</a>
</li>
<li><a href="e0z3m100.htm#idx50" class="indexlink">IBM z/OS Management Facility</a>
</li>
<li><a href="e0z3m100.htm#idx70" class="indexlink">ICKDSF, no migration actions for</a>
</li>
<li>ICLI component
<a href="e0z3m100.htm#idx327" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx639" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx841" class="indexlink">(3)</a>, <a href="e0z3m100.htm#idx1309" class="indexlink">(4)</a>
</li>
<li><a href="e0z3m100.htm#idx818" class="indexlink">ICSF</a>
</li>
<li><a href="e0z3m100.htm#idx892" class="indexlink">ICSF, ensuring that the CSFPUTIL utility is not used to initialize a PKDS</a>
</li>
<li>ICSF and NSS daemon
<a href="e0z3m100.htm#idx329" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx843" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx911" class="indexlink">ICSF master keys</a>
</li>
<li><a href="e0z3m100.htm#idx891" class="indexlink">ICSF migration action</a>
</li>
<li>ICSF migration actions
<a href="e0z3m100.htm#idx359" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx879" class="indexlink">(2)</a>
</li>
<li>identity propagation
<a href="e0z3m100.htm#idx583" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx596" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx1238" class="indexlink">(3)</a>, <a href="e0z3m100.htm#idx1254" class="indexlink">(4)</a>, <a href="e0z3m100.htm#idx1267" class="indexlink">(5)</a>
</li>
<li>IEAOPTxx keyword
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx738" class="indexlink">HIPERDISPATCH=YES, default</a>
</li>
</ul>
</li>
<li>IEASYSxx
<ul class="indexlist">
<li>WARNUND
<a href="e0z3m100.htm#idx269" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx687" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx951" class="indexlink">IEBCOPY update</a>
</li>
<li>IEBCOPY utility
<a href="e0z3m100.htm#idx410" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx944" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx108" class="indexlink">IFAPRDxx product IDe</a>
</li>
<li><a href="e0z3m100.htm#idx930" class="indexlink">IGGCATxx</a>
</li>
<li><a href="e0z3m100.htm#idx816" class="indexlink">IKE daemon</a>
</li>
<li>IKE daemon, Communications server
<a href="e0z3m100.htm#idx330" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx844" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx215" class="indexlink">InfiniBand</a>
</li>
<li><a href="e0z3m100.htm#idx1092" class="indexlink">Infoprint Server</a>
</li>
<li>Infoprint Server migration actions
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1096" class="indexlink">after first IPL</a>
</li>
<li><a href="e0z3m100.htm#idx1082" class="indexlink">before first IPL</a>
</li>
<li>before installing
<a href="e0z3m100.htm#idx473" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1074" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx40" class="indexlink">installation steps</a>
</li>
<li>installing, migration actions before
<ul class="indexlist">
<li>Infoprint Server
<a href="e0z3m100.htm#idx476" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1077" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx71" class="indexlink">Integrated Security Services, no migration actions for</a>
</li>
<li>integrity of SMS control data sets
<a href="e0z3m100.htm#idx389" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx921" class="indexlink">(2)</a>
</li>
<li>Internet address
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx231" class="indexlink">for CFCC levels and processors</a>
</li>
<li><a href="e0z3m100.htm#idx228" class="indexlink">for CFSizer tool</a>
</li>
<li><a href="e0z3m100.htm#idx208" class="indexlink">for Enhanced PSP Tool</a>
</li>
<li>for flashes
<a href="e0z3m100.htm#idx143" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx148" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx134" class="indexlink">for ISVs</a>
</li>
<li><a href="e0z3m100.htm#idx92" class="indexlink">for PSP buckets</a>
</li>
<li><a href="e0z3m100.htm#idx38" class="indexlink">for z/OS publications</a>
</li>
<li><a href="e0z3m100.htm#idx101" class="indexlink">for zSoftCap</a>
</li>
</ul>
</li>
<li>Intrusion Detection Services
<ul class="indexlist">
<li>IP Fragment attack type
<a href="e0z3m100.htm#idx316" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx796" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx820" class="indexlink">Intrusion Detection Services and traffic monitoring</a>
</li>
<li><a href="e0z3m100.htm#idx1329" class="indexlink">invalid REXX variables</a>
</li>
<li>ioeagfmt (zFS batch utility)
<a href="e0z3m100.htm#idx463" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1064" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1053" class="indexlink">IOEFSPRM</a>
</li>
<li>IOEFSPRM configuration file
<ul class="indexlist">
<li>accept
<a href="e0z3m100.htm#idx630" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1295" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>IOSSPOF macro
<a href="e0z3m100.htm#idx263" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx681" class="indexlink">(2)</a>
</li>
<li>IP fragment
<ul class="indexlist">
<li>before installing
<a href="e0z3m100.htm#idx314" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx794" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx1079" class="indexlink">IP PrintWay migration from basic mode to extended mode</a>
</li>
<li><a href="e0z3m100.htm#idx832" class="indexlink">IPCONFIG and IPCONFIG6, Communications Server</a>
</li>
<li><a href="e0z3m100.htm#idx116" class="indexlink">IPCS, setting up</a>
</li>
<li>IPL, migration actions after first
<ul class="indexlist">
<li>BCP
<a href="e0z3m100.htm#idx300" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx760" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx768" class="indexlink">(3)</a>
</li>
<li>Communications Server
<a href="e0z3m100.htm#idx356" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx876" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx379" class="indexlink">Cryptographic Services</a>
</li>
<li>DFSMS
<a href="e0z3m100.htm#idx424" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1010" class="indexlink">(2)</a>
</li>
<li>DFSORT
<a href="e0z3m100.htm#idx441" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1030" class="indexlink">(2)</a>
</li>
<li>Distributed File Service
<a href="e0z3m100.htm#idx468" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1069" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1100" class="indexlink">Infoprint Server</a>
</li>
<li>JES2
<a href="e0z3m100.htm#idx489" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1115" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1165" class="indexlink">Language Environment</a>
</li>
<li>RMF
<a href="e0z3m100.htm#idx537" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1196" class="indexlink">(2)</a>
</li>
<li>SDSF
<a href="e0z3m100.htm#idx559" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1220" class="indexlink">(2)</a>
</li>
<li>Security Server
<a href="e0z3m100.htm#idx589" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1260" class="indexlink">(2)</a>
</li>
<li>sysplex
<a href="e0z3m100.htm#idx251" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx669" class="indexlink">(2)</a>
</li>
<li>XL C/C++
<a href="e0z3m100.htm#idx614" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1279" class="indexlink">(2)</a>
</li>
<li>z/OS UNIX
<a href="e0z3m100.htm#idx647" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1319" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx1327" class="indexlink">(3)</a>
</li>
</ul>
</li>
<li>IPL, migration actions before first
<ul class="indexlist">
<li>BCP
<a href="e0z3m100.htm#idx281" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx711" class="indexlink">(2)</a>
</li>
<li>Communications Server
<a href="e0z3m100.htm#idx340" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx854" class="indexlink">(2)</a>
</li>
<li>Cryptographic Services
<a href="e0z3m100.htm#idx365" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx889" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx897" class="indexlink">(3)</a>
</li>
<li>DFSMS
<a href="e0z3m100.htm#idx403" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx937" class="indexlink">(2)</a>
</li>
<li>DFSORT
<a href="e0z3m100.htm#idx435" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1024" class="indexlink">(2)</a>
</li>
<li>Distributed File Service
<a href="e0z3m100.htm#idx459" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1044" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx114" class="indexlink">general</a>
</li>
<li><a href="e0z3m100.htm#idx1086" class="indexlink">Infoprint Server</a>
</li>
<li>JES3
<a href="e0z3m100.htm#idx504" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1132" class="indexlink">(2)</a>
</li>
<li>Library Server
<a href="e0z3m100.htm#idx515" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1172" class="indexlink">(2)</a>
</li>
<li>RMF
<a href="e0z3m100.htm#idx524" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1181" class="indexlink">(2)</a>
</li>
<li>SDSF
<a href="e0z3m100.htm#idx550" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1211" class="indexlink">(2)</a>
</li>
<li>Security Server
<a href="e0z3m100.htm#idx573" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1244" class="indexlink">(2)</a>
</li>
<li>sysplex
<a href="e0z3m100.htm#idx244" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx662" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx608" class="indexlink">XL C/C++</a>
</li>
<li>z/OS UNIX
<a href="e0z3m100.htm#idx636" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1306" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>IPL text, creating
<a href="e0z3m100.htm#idx270" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx700" class="indexlink">(2)</a>
</li>
<li>IPv6
<ul class="indexlist">
<li>before installing
<a href="e0z3m100.htm#idx311" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx791" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>IPv6 support for policy-based routing
<a href="e0z3m100.htm#idx321" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx801" class="indexlink">(2)</a>
</li>
<li>IRRMIN00 utility, RACF
<a href="e0z3m100.htm#idx594" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1265" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1230" class="indexlink">ISFPARMS</a>
</li>
<li>ISFPARMS, SDSF
<ul class="indexlist">
<li>reassembling
<a href="e0z3m100.htm#idx554" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1215" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx132" class="indexlink">ISV products, reconnecting</a>
</li>
<li><a href="e0z3m100.htm#idx836" class="indexlink">IVTCSM ASSIGN_BUFFER requests</a>
</li>
</ul>
<strong><a name="IDX1_4A" href="#IDX0_4A">J</a></strong>
<ul class="indexlist">
<li>JCLERR parameter
<a href="e0z3m100.htm#idx493" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1119" class="indexlink">(2)</a>
</li>
<li>JES2
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1121" class="indexlink">z11 mode</a>
</li>
</ul>
</li>
<li>JES2 migration actions
<ul class="indexlist">
<li>after first IPL
<a href="e0z3m100.htm#idx485" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1111" class="indexlink">(2)</a>
</li>
<li>before installing
<a href="e0z3m100.htm#idx478" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1104" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx1138" class="indexlink">JES3 DLOG</a>
</li>
<li><a href="e0z3m100.htm#idx1145" class="indexlink">JES3 migration actions</a>
<ul class="indexlist">
<li>before first IPL
<a href="e0z3m100.htm#idx500" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1128" class="indexlink">(2)</a>
</li>
<li>before installing
<a href="e0z3m100.htm#idx496" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1124" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>JES3 release level format
<a href="e0z3m100.htm#idx506" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1134" class="indexlink">(2)</a>
</li>
<li>JESJOBS access profiles
<a href="e0z3m100.htm#idx482" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1108" class="indexlink">(2)</a>
</li>
<li>Job Modify SSI 85
<ul class="indexlist">
<li>authority
<a href="e0z3m100.htm#idx484" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1110" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>JOBDEF statement
<a href="e0z3m100.htm#idx494" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1120" class="indexlink">(2)</a>
</li>
<li>JVM applications
<a href="e0z3m100.htm#idx629" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1294" class="indexlink">(2)</a>
</li>
</ul>
<strong><a name="IDX1_4B" href="#IDX0_4B">K</a></strong>
<ul class="indexlist">
<li>keyboard
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1331" class="indexlink">navigation</a>
</li>
<li><a href="e0z3m100.htm#idx1337" class="indexlink">PF keys</a>
</li>
<li><a href="e0z3m100.htm#idx1335" class="indexlink">shortcut keys</a>
</li>
</ul>
</li>
</ul>
<strong><a name="IDX1_4C" href="#IDX0_4C">L</a></strong>
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1155" class="indexlink">Language Environment</a>
</li>
<li>Language Environment migration actions
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1161" class="indexlink">after first IPL</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx214" class="indexlink">large page support</a>
</li>
<li>large pages
<a href="e0z3m100.htm#idx267" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx685" class="indexlink">(2)</a>
</li>
<li>library lookaside (LLA)
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx727" class="indexlink">restart</a>
</li>
</ul>
</li>
<li>Library Server InfoCenters
<a href="e0z3m100.htm#idx518" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1175" class="indexlink">(2)</a>
</li>
<li>Library Server migration actions
<ul class="indexlist">
<li>before first IPL
<a href="e0z3m100.htm#idx511" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1168" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>link pack area (LPA)
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1150" class="indexlink">Language Environment load modules in</a>
</li>
<li><a href="e0z3m100.htm#idx222" class="indexlink">relieving virtual storage constraint with</a>
</li>
</ul>
</li>
<li>linkage conventions
<a href="e0z3m100.htm#idx289" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx719" class="indexlink">(2)</a>
</li>
<li>LIST DUMPCLASS command, DFSMShsm
<a href="e0z3m100.htm#idx415" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx959" class="indexlink">(2)</a>
</li>
<li>LISTCAT
<ul class="indexlist">
<li>removal of NOIMBED and NOREPLICAT from output
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx929" class="indexlink">migration action for</a>
</li>
</ul>
</li>
</ul>
</li>
<li>LPA (link pack area)
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1151" class="indexlink">Language Environment load modules in</a>
</li>
<li><a href="e0z3m100.htm#idx223" class="indexlink">relieving virtual storage constraint with</a>
</li>
</ul>
</li>
</ul>
<strong><a name="IDX1_4D" href="#IDX0_4D">M</a></strong>
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx94" class="indexlink">maintenance, coexistence and fallback</a>
</li>
<li><a href="e0z3m100.htm#idx51" class="indexlink">Management Facility, IBM z/OS</a>
</li>
<li><a href="e0z3m100.htm#idx912" class="indexlink">master keys, ICSF</a>
</li>
<li><a href="e0z3m100.htm#idx159" class="indexlink">MAXUSER</a>
</li>
<li>MEMLIMIT parameter
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx141" class="indexlink">determining virtual storage with</a>
</li>
</ul>
</li>
<li>memory pool
<a href="e0z3m100.htm#idx292" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx721" class="indexlink">(2)</a>
</li>
<li>message automation
<a href="e0z3m100.htm#idx284" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx714" class="indexlink">(2)</a>
</li>
<li>messages
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx976" class="indexlink">ARC1809I</a>
</li>
<li><a href="e0z3m100.htm#idx725" class="indexlink">XCF/XES</a>
</li>
</ul>
</li>
<li>Messages
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1144" class="indexlink">IAT3100</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx988" class="indexlink">messages, changed type</a>
</li>
<li>messages, updating automation for changed
<a href="e0z3m100.htm#idx125" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx977" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx987" class="indexlink">(3)</a>
</li>
<li><a href="e0z3m100.htm#idx72" class="indexlink">Metal C Runtime Library, no migration actions for</a>
</li>
<li><a href="e0z3m100.htm#idx806" class="indexlink">MIB object, SNMP sysObjectID</a>
</li>
<li><a href="e0z3m100.htm#idx73" class="indexlink">MICR/OCR, no migration actions for</a>
</li>
<li><a href="e0z3m100.htm#idx12" class="indexlink">migration, definition of</a>
</li>
<li>migration actions
<ul class="indexlist">
<li>after first IPL
<ul class="indexlist">
<li>BCP
<a href="e0z3m100.htm#idx297" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx757" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx765" class="indexlink">(3)</a>
</li>
<li>Communications Server
<a href="e0z3m100.htm#idx353" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx873" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx376" class="indexlink">Cryptographic Services</a>
</li>
<li>DFSMS
<a href="e0z3m100.htm#idx421" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1007" class="indexlink">(2)</a>
</li>
<li>DFSORT
<a href="e0z3m100.htm#idx438" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1027" class="indexlink">(2)</a>
</li>
<li>Distributed File Service
<a href="e0z3m100.htm#idx465" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1066" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1097" class="indexlink">Infoprint Server</a>
</li>
<li>JES2
<a href="e0z3m100.htm#idx486" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1112" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1162" class="indexlink">Language Environment</a>
</li>
<li>RMF
<a href="e0z3m100.htm#idx534" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1193" class="indexlink">(2)</a>
</li>
<li>SDSF
<a href="e0z3m100.htm#idx556" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1217" class="indexlink">(2)</a>
</li>
<li>Security Server
<a href="e0z3m100.htm#idx586" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1257" class="indexlink">(2)</a>
</li>
<li>sysplex
<a href="e0z3m100.htm#idx248" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx666" class="indexlink">(2)</a>
</li>
<li>XL C/C++
<a href="e0z3m100.htm#idx611" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1276" class="indexlink">(2)</a>
</li>
<li>z/OS UNIX
<a href="e0z3m100.htm#idx644" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1316" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx1324" class="indexlink">(3)</a>
</li>
</ul>
</li>
<li>BCP
<a href="e0z3m100.htm#idx253" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx671" class="indexlink">(2)</a>
</li>
<li>before first IPL
<ul class="indexlist">
<li>BCP
<a href="e0z3m100.htm#idx278" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx708" class="indexlink">(2)</a>
</li>
<li>Communications Server
<a href="e0z3m100.htm#idx337" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx851" class="indexlink">(2)</a>
</li>
<li>Cryptographic Services
<a href="e0z3m100.htm#idx362" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx886" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx894" class="indexlink">(3)</a>
</li>
<li>DFSMS
<a href="e0z3m100.htm#idx400" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx934" class="indexlink">(2)</a>
</li>
<li>DFSORT
<a href="e0z3m100.htm#idx432" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1021" class="indexlink">(2)</a>
</li>
<li>Distributed File Service
<a href="e0z3m100.htm#idx456" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1041" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx110" class="indexlink">general</a>
</li>
<li><a href="e0z3m100.htm#idx1083" class="indexlink">Infoprint Server</a>
</li>
<li>JES3
<a href="e0z3m100.htm#idx501" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1129" class="indexlink">(2)</a>
</li>
<li>Library Server
<a href="e0z3m100.htm#idx512" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1169" class="indexlink">(2)</a>
</li>
<li>RMF
<a href="e0z3m100.htm#idx521" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1178" class="indexlink">(2)</a>
</li>
<li>SDSF
<a href="e0z3m100.htm#idx547" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1208" class="indexlink">(2)</a>
</li>
<li>Security Server
<a href="e0z3m100.htm#idx570" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1241" class="indexlink">(2)</a>
</li>
<li>sysplex
<a href="e0z3m100.htm#idx241" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx659" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx605" class="indexlink">XL C/C++</a>
</li>
<li>z/OS UNIX
<a href="e0z3m100.htm#idx633" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1303" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>before installing
<ul class="indexlist">
<li>BCP
<a href="e0z3m100.htm#idx257" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx675" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx882" class="indexlink">Cryptographic Services</a>
</li>
<li>DFSMS
<a href="e0z3m100.htm#idx383" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx915" class="indexlink">(2)</a>
</li>
<li>Distributed File Service
<a href="e0z3m100.htm#idx452" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1049" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx86" class="indexlink">general</a>
</li>
<li>Infoprint Server
<a href="e0z3m100.htm#idx474" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1075" class="indexlink">(2)</a>
</li>
<li>JES2
<a href="e0z3m100.htm#idx479" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1105" class="indexlink">(2)</a>
</li>
<li>JES3
<a href="e0z3m100.htm#idx497" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1125" class="indexlink">(2)</a>
</li>
<li>Security Server
<a href="e0z3m100.htm#idx565" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1233" class="indexlink">(2)</a>
</li>
<li>sysplex
<a href="e0z3m100.htm#idx236" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx654" class="indexlink">(2)</a>
</li>
<li>XL C/C++
<a href="e0z3m100.htm#idx601" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1272" class="indexlink">(2)</a>
</li>
<li>z/OS UNIX
<a href="e0z3m100.htm#idx626" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1291" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>BookManager BUILD
<a href="e0z3m100.htm#idx304" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx470" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx781" class="indexlink">(3)</a>, <a href="e0z3m100.htm#idx783" class="indexlink">(4)</a>, <a href="e0z3m100.htm#idx1071" class="indexlink">(5)</a>
</li>
<li>C/C++
<a href="e0z3m100.htm#idx598" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1269" class="indexlink">(2)</a>
</li>
<li>Communications Server
<a href="e0z3m100.htm#idx306" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx786" class="indexlink">(2)</a>
</li>
<li>Cryptographic Services
<a href="e0z3m100.htm#idx358" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx878" class="indexlink">(2)</a>
</li>
<li>DFSMS
<a href="e0z3m100.htm#idx381" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx913" class="indexlink">(2)</a>
</li>
<li>DFSORT
<a href="e0z3m100.htm#idx430" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1019" class="indexlink">(2)</a>
</li>
<li>Distributed File Service
<a href="e0z3m100.htm#idx450" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1039" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx83" class="indexlink">for everyone</a>
</li>
<li><a href="e0z3m100.htm#idx82" class="indexlink">general</a>
</li>
<li><a href="e0z3m100.htm#idx161" class="indexlink">hardware</a>
</li>
<li>Infoprint Server
<a href="e0z3m100.htm#idx472" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1073" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1103" class="indexlink">JES2</a>
</li>
<li>JES3
<a href="e0z3m100.htm#idx495" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1123" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1147" class="indexlink">Language Environment</a>
</li>
<li>Library Server
<a href="e0z3m100.htm#idx510" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1167" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx54" class="indexlink">none, elements and features with</a>
</li>
<li>RMF
<a href="e0z3m100.htm#idx519" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1176" class="indexlink">(2)</a>
</li>
<li>SDSF
<a href="e0z3m100.htm#idx545" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1206" class="indexlink">(2)</a>
</li>
<li>Security Server
<a href="e0z3m100.htm#idx563" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1231" class="indexlink">(2)</a>
</li>
<li>sysplex
<a href="e0z3m100.htm#idx233" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx651" class="indexlink">(2)</a>
</li>
<li>XL C/C++
<a href="e0z3m100.htm#idx599" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1270" class="indexlink">(2)</a>
</li>
<li>z/OS UNIX
<a href="e0z3m100.htm#idx621" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1286" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>migration actions to perform, meaning of
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx21" class="indexlink">after first IPL</a>
</li>
<li><a href="e0z3m100.htm#idx19" class="indexlink">before first IPL</a>
</li>
<li><a href="e0z3m100.htm#idx17" class="indexlink">before installing</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx47" class="indexlink">migration health checks</a>
</li>
<li><a href="e0z3m100.htm#idx41" class="indexlink">migration steps</a>
</li>
<li>modifications, user
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx127" class="indexlink">examining</a>
</li>
<li><a href="e0z3m100.htm#idx1158" class="indexlink">for Language Environment options</a>
</li>
</ul>
</li>
<li>Monitor III version, using correct
<a href="e0z3m100.htm#idx539" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1198" class="indexlink">(2)</a>
</li>
<li>MTFTPS
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx731" class="indexlink">discontinue use</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx994" class="indexlink">MVT (SMS) chain rebuild (DFSMShsm), removal of patch preventing</a>
</li>
</ul>
<strong><a name="IDX1_4E" href="#IDX0_4E">N</a></strong>
<ul class="indexlist">
<li>navigation
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1332" class="indexlink">keyboard</a>
</li>
</ul>
</li>
<li>Netstat enhancementss
<a href="e0z3m100.htm#idx350" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx864" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx155" class="indexlink">new data sets</a>
</li>
<li><a href="e0z3m100.htm#idx74" class="indexlink">NFS, no migration actions for</a>
</li>
<li>NMI applications
<a href="e0z3m100.htm#idx318" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx798" class="indexlink">(2)</a>
</li>
<li>normalization of RACF user names
<a href="e0z3m100.htm#idx584" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx597" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx1239" class="indexlink">(3)</a>, <a href="e0z3m100.htm#idx1255" class="indexlink">(4)</a>, <a href="e0z3m100.htm#idx1268" class="indexlink">(5)</a>
</li>
<li>notes files, Library Server
<a href="e0z3m100.htm#idx517" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1174" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1340" class="indexlink">Notices</a>
</li>
<li>NOZFS
<ul class="indexlist">
<li>RMF data gathering option
<a href="e0z3m100.htm#idx542" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1201" class="indexlink">(2)</a>
</li>
</ul>
</li>
</ul>
<strong><a name="IDX1_4F" href="#IDX0_4F">O</a></strong>
<ul class="indexlist">
<li>OAM DB2 BIND jobs
<a href="e0z3m100.htm#idx417" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1000" class="indexlink">(2)</a>
</li>
<li>OCSF directory migration
<a href="e0z3m100.htm#idx367" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx899" class="indexlink">(2)</a>
</li>
<li>OCSF migration actions
<a href="e0z3m100.htm#idx360" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx880" class="indexlink">(2)</a>
</li>
<li>OMPROUTE
<a href="e0z3m100.htm#idx348" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx862" class="indexlink">(2)</a>
</li>
<li>OMROUTE
<ul class="indexlist">
<li>before first IPL
<a href="e0z3m100.htm#idx345" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx859" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>one-stage JCL
<a href="e0z3m100.htm#idx274" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx704" class="indexlink">(2)</a>
</li>
<li>one-step JCL
<a href="e0z3m100.htm#idx273" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx703" class="indexlink">(2)</a>
</li>
<li>Open/Close/End of Volume ABEND messages
<a href="e0z3m100.htm#idx396" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx928" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx952" class="indexlink">(3)</a>
</li>
<li><a href="e0z3m100.htm#idx745" class="indexlink">OPERLOG EMCS console name change</a>
</li>
<li><a href="e0z3m100.htm#idx1226" class="indexlink">OPERLOG panel</a>
</li>
<li><a href="e0z3m100.htm#idx807" class="indexlink">OSNMPD.DATA file, SNMP sysObjectID MIB object in</a>
</li>
<li><a href="e0z3m100.htm#idx27" class="indexlink">other system (coexistence or fallback) requirements, meaning of</a>
</li>
<li>OUTDEF statement
<a href="e0z3m100.htm#idx492" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1118" class="indexlink">(2)</a>
</li>
</ul>
<strong><a name="IDX1_50" href="#IDX0_50">P</a></strong>
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx216" class="indexlink">Parallel Sysplex InfiniBand</a>
</li>
<li>Parallel Sysplex migration actions
<ul class="indexlist">
<li>after first IPL
<a href="e0z3m100.htm#idx247" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx665" class="indexlink">(2)</a>
</li>
<li>before first IPL
<a href="e0z3m100.htm#idx240" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx658" class="indexlink">(2)</a>
</li>
<li>before installing
<a href="e0z3m100.htm#idx235" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx653" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>parmlib
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx117" class="indexlink">used by IPCS</a>
</li>
<li><a href="e0z3m100.htm#idx119" class="indexlink">using shipped members of</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx829" class="indexlink">password or password phrase</a>
</li>
<li><a href="e0z3m100.htm#idx978" class="indexlink">patch disabling unwanted ARC1809I messages (DFSMShsm), removal of</a>
</li>
<li><a href="e0z3m100.htm#idx991" class="indexlink">patch preventing the SMS MVT chain rebuild (DFSMShsm), removal of</a>
</li>
<li><a href="e0z3m100.htm#idx154" class="indexlink">paths, deleted</a>
</li>
<li>PCI Express
<a href="e0z3m100.htm#idx287" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx717" class="indexlink">(2)</a>
</li>
<li>PCIE
<a href="e0z3m100.htm#idx286" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx716" class="indexlink">(2)</a>
</li>
<li>PDA trace
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx961" class="indexlink">at startup, DFSMShsm</a>
</li>
<li><a href="e0z3m100.htm#idx962" class="indexlink">default change</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx157" class="indexlink">PDSE sharing restrictions</a>
</li>
<li><a href="e0z3m100.htm#idx777" class="indexlink">PFA</a>
</li>
<li>PFA (Predictive Failure Analysis)
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx749" class="indexlink">directory setting</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx688" class="indexlink">PGSER</a>
</li>
<li>PGSER PROTECT/UNPROTECT
<a href="e0z3m100.htm#idx265" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx683" class="indexlink">(2)</a>
</li>
<li>post-IPL migration actions
<ul class="indexlist">
<li>Communications Server
<a href="e0z3m100.htm#idx357" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx877" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx380" class="indexlink">Cryptographic Services</a>
</li>
<li>DFSMS
<a href="e0z3m100.htm#idx425" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1011" class="indexlink">(2)</a>
</li>
<li>DFSORT
<a href="e0z3m100.htm#idx442" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1031" class="indexlink">(2)</a>
</li>
<li>Distributed File Service
<a href="e0z3m100.htm#idx469" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1070" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1101" class="indexlink">Infoprint Server</a>
</li>
<li>JES2
<a href="e0z3m100.htm#idx490" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1116" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1166" class="indexlink">Language Environment</a>
</li>
<li>RMF
<a href="e0z3m100.htm#idx538" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1197" class="indexlink">(2)</a>
</li>
<li>SDSF
<a href="e0z3m100.htm#idx560" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1221" class="indexlink">(2)</a>
</li>
<li>Security Server
<a href="e0z3m100.htm#idx590" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1261" class="indexlink">(2)</a>
</li>
<li>sysplex
<a href="e0z3m100.htm#idx252" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx670" class="indexlink">(2)</a>
</li>
<li>XL C/C++
<a href="e0z3m100.htm#idx609" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx615" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx1280" class="indexlink">(3)</a>
</li>
<li>z/OS UNIX
<a href="e0z3m100.htm#idx648" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1320" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx1328" class="indexlink">(3)</a>
</li>
</ul>
</li>
<li>pre-IPL migration actions
<ul class="indexlist">
<li>BCP
<a href="e0z3m100.htm#idx282" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx712" class="indexlink">(2)</a>
</li>
<li>Communications Server
<a href="e0z3m100.htm#idx341" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx855" class="indexlink">(2)</a>
</li>
<li>Cryptographic Services
<a href="e0z3m100.htm#idx366" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx890" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx898" class="indexlink">(3)</a>
</li>
<li>DFSMS
<a href="e0z3m100.htm#idx404" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx938" class="indexlink">(2)</a>
</li>
<li>DFSORT
<a href="e0z3m100.htm#idx436" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1025" class="indexlink">(2)</a>
</li>
<li>Distributed File Service
<a href="e0z3m100.htm#idx460" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1045" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx115" class="indexlink">general</a>
</li>
<li><a href="e0z3m100.htm#idx1087" class="indexlink">Infoprint Server</a>
</li>
<li>JES3
<a href="e0z3m100.htm#idx505" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1133" class="indexlink">(2)</a>
</li>
<li>Library Server
<a href="e0z3m100.htm#idx516" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1173" class="indexlink">(2)</a>
</li>
<li>RMF
<a href="e0z3m100.htm#idx525" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1182" class="indexlink">(2)</a>
</li>
<li>SDSF
<a href="e0z3m100.htm#idx551" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1212" class="indexlink">(2)</a>
</li>
<li>Security Server
<a href="e0z3m100.htm#idx574" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1245" class="indexlink">(2)</a>
</li>
<li>sysplex
<a href="e0z3m100.htm#idx245" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx663" class="indexlink">(2)</a>
</li>
<li>z/OS UNIX
<a href="e0z3m100.htm#idx637" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1307" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>Predictive Failure Analysis (PFA)
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx689" class="indexlink">DASD</a>
</li>
<li><a href="e0z3m100.htm#idx748" class="indexlink">directory setting</a>
</li>
<li><a href="e0z3m100.htm#idx690" class="indexlink">storage requirements</a>
</li>
</ul>
</li>
<li>preinstallation migration actions
<ul class="indexlist">
<li>BCP
<a href="e0z3m100.htm#idx259" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx677" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx884" class="indexlink">Cryptographic Services</a>
</li>
<li>DFSMS
<a href="e0z3m100.htm#idx385" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx917" class="indexlink">(2)</a>
</li>
<li>Distributed File Service
<a href="e0z3m100.htm#idx454" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1051" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx88" class="indexlink">general</a>
</li>
<li>JES
<a href="e0z3m100.htm#idx481" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx499" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx1107" class="indexlink">(3)</a>, <a href="e0z3m100.htm#idx1127" class="indexlink">(4)</a>
</li>
<li>Security Server
<a href="e0z3m100.htm#idx567" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1235" class="indexlink">(2)</a>
</li>
<li>sysplex
<a href="e0z3m100.htm#idx238" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx656" class="indexlink">(2)</a>
</li>
<li>XL C/C++
<a href="e0z3m100.htm#idx603" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1274" class="indexlink">(2)</a>
</li>
<li>z/OS UNIX
<a href="e0z3m100.htm#idx628" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1293" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx992" class="indexlink">preventing the SMS MVT chain rebuild (DFSMShsm), removal of patch</a>
</li>
<li><a href="e0z3m100.htm#idx1088" class="indexlink">printer inventory, migrating</a>
</li>
<li><a href="e0z3m100.htm#idx752" class="indexlink">problem determination and console commands</a>
</li>
<li>problem documentation upload utility (PDUU)
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx732" class="indexlink">support for</a>
</li>
</ul>
</li>
<li>problem management
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx774" class="indexlink">PFA</a>
</li>
<li><a href="e0z3m100.htm#idx744" class="indexlink">Runtime Diagnostics</a>
</li>
<li><a href="e0z3m100.htm#idx773" class="indexlink">Runtime Diagnostics and PFA</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx137" class="indexlink">procedures, updating operational</a>
</li>
<li>Process Manager
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1299" class="indexlink">migration action</a>
</li>
</ul>
</li>
<li>processors
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx202" class="indexlink">migrating to z10</a>
</li>
<li>migrating to z114
<a href="e0z3m100.htm#idx175" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx190" class="indexlink">(2)</a>
</li>
<li>migrating to z196
<a href="e0z3m100.htm#idx170" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx185" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx166" class="indexlink">migrating to zEC12</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx121" class="indexlink">proclib, using shipped members of</a>
</li>
<li><a href="e0z3m100.htm#idx784" class="indexlink">Provisioning Manager</a>
</li>
<li><a href="e0z3m100.htm#idx217" class="indexlink">PSIFB (Parallel Sysplex InfiniBand)</a>
</li>
<li>PSP bucket
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx89" class="indexlink">reviewing</a>
</li>
<li><a href="e0z3m100.htm#idx90" class="indexlink">upgrade IDs</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx34" class="indexlink">publications, related</a>
</li>
</ul>
<strong><a name="IDX1_51" href="#IDX0_51">Q</a></strong>
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx812" class="indexlink">QDIO inbound workload queueing for EE traffic</a>
</li>
<li><a href="e0z3m100.htm#idx780" class="indexlink">qnames</a>
</li>
</ul>
<strong><a name="IDX1_52" href="#IDX0_52">R</a></strong>
<ul class="indexlist">
<li>RACF database templates, updating
<a href="e0z3m100.htm#idx593" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1264" class="indexlink">(2)</a>
</li>
<li>RACF migration actions
<ul class="indexlist">
<li>after first IPL
<a href="e0z3m100.htm#idx591" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1262" class="indexlink">(2)</a>
</li>
<li>before first IPL
<a href="e0z3m100.htm#idx575" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1246" class="indexlink">(2)</a>
</li>
<li>before installing
<a href="e0z3m100.htm#idx568" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1236" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>RACF tape profile processing
<a href="e0z3m100.htm#idx416" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx999" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx908" class="indexlink">RACF user ids and CSFIQA resource of the CSFSERV class</a>
</li>
<li><a href="e0z3m100.htm#idx3" class="indexlink">read this document, who should</a>
</li>
<li><a href="e0z3m100.htm#idx838" class="indexlink">reason code 26</a>
</li>
<li><a href="e0z3m100.htm#idx996" class="indexlink">rebuild of chain (DFSMShsm), removal of patch preventing SMS MVT</a>
</li>
<li><a href="e0z3m100.htm#idx32" class="indexlink">reference information, meaning of</a>
</li>
<li><a href="e0z3m100.htm#idx1093" class="indexlink">region size change</a>
</li>
<li><a href="e0z3m100.htm#idx1091" class="indexlink">region size change, Infoprint Server</a>
</li>
<li><a href="e0z3m100.htm#idx36" class="indexlink">related documentation</a>
</li>
<li><a href="e0z3m100.htm#idx990" class="indexlink">Removal of the patch preventing the SMS MVT chain rebuild (DFSMShsm)</a>
</li>
<li><a href="e0z3m100.htm#idx152" class="indexlink">removed data sets and paths</a>
</li>
<li><a href="e0z3m100.htm#idx46" class="indexlink">REPORT MISSINGFIX</a>
</li>
<li><a href="e0z3m100.htm#idx24" class="indexlink">required action, meaning of</a>
</li>
<li>resolver
<ul class="indexlist">
<li>resolver address space initialization
<a href="e0z3m100.htm#idx344" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx858" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx28" class="indexlink">restrictions, meaning of</a>
</li>
<li>RMF
<ul class="indexlist">
<li>ERB2XDGS
<a href="e0z3m100.htm#idx526" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1183" class="indexlink">(2)</a>
</li>
<li>ERB3XDRS
<a href="e0z3m100.htm#idx527" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1184" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1205" class="indexlink">SMF 72.5 data collection</a>
</li>
<li>SMF 74.9 data collection
<a href="e0z3m100.htm#idx544" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1203" class="indexlink">(2)</a>
</li>
<li>ZFS
<a href="e0z3m100.htm#idx540" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1199" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>RMF, RACF and GPMSERVE Started Task
<a href="e0z3m100.htm#idx531" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1188" class="indexlink">(2)</a>
</li>
<li>RMF migration actions
<ul class="indexlist">
<li>after first IPL
<a href="e0z3m100.htm#idx533" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1192" class="indexlink">(2)</a>
</li>
<li>before first IPL
<a href="e0z3m100.htm#idx520" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1177" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>RMF Monitor II Sysplex Data Gathering services
<a href="e0z3m100.htm#idx529" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1186" class="indexlink">(2)</a>
</li>
<li>RMF Monitor III Sysplex Data Retrieval services
<a href="e0z3m100.htm#idx528" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1185" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx104" class="indexlink">root size, z/OS</a>
</li>
<li>router table, RACF
<a href="e0z3m100.htm#idx578" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1249" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx75" class="indexlink">Run-Time Library Extensions, no migration actions for</a>
</li>
<li>Runtime Diagnostics
<a href="e0z3m100.htm#idx740" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx741" class="indexlink">(2)</a>
<ul class="indexlist">
<li>HZR address space
<a href="e0z3m100.htm#idx743" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx772" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx1156" class="indexlink">runtime options report</a>
</li>
</ul>
<strong><a name="IDX1_53" href="#IDX0_53">S</a></strong>
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx695" class="indexlink">S99ACUCB</a>
</li>
<li><a href="e0z3m100.htm#idx694" class="indexlink">S99DSABA</a>
</li>
<li><a href="e0z3m100.htm#idx823" class="indexlink">scan detection</a>
</li>
<li>SCDS (source control data set), ensuring integrity of
<a href="e0z3m100.htm#idx391" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx923" class="indexlink">(2)</a>
</li>
<li>screen readers
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1338" class="indexlink">accessibility</a>
</li>
</ul>
</li>
<li>SDSF, extended console name
<a href="e0z3m100.htm#idx562" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1223" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1229" class="indexlink">SDSF custom properties</a>
</li>
<li>SDSF migration actions
<ul class="indexlist">
<li>after first IPL
<a href="e0z3m100.htm#idx555" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1216" class="indexlink">(2)</a>
</li>
<li>before first IPL
<a href="e0z3m100.htm#idx546" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1207" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>Security Server migration actions
<ul class="indexlist">
<li>after first IPL
<a href="e0z3m100.htm#idx585" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1256" class="indexlink">(2)</a>
</li>
<li>before first IPL
<a href="e0z3m100.htm#idx569" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1240" class="indexlink">(2)</a>
</li>
<li>before installing
<a href="e0z3m100.htm#idx564" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1232" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>server, z10
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx205" class="indexlink">coexistence requirements</a>
</li>
<li><a href="e0z3m100.htm#idx200" class="indexlink">migrating to</a>
</li>
<li><a href="e0z3m100.htm#idx201" class="indexlink">software support features</a>
</li>
</ul>
</li>
<li>server, z114
<ul class="indexlist">
<li>software support features
<a href="e0z3m100.htm#idx177" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx192" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>server, z196
<ul class="indexlist">
<li>software support features
<a href="e0z3m100.htm#idx172" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx187" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>server, zEC12
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx164" class="indexlink">software support features</a>
</li>
</ul>
</li>
<li>SETLOAD IEASYM
<a href="e0z3m100.htm#idx301" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx761" class="indexlink">(2)</a>
</li>
<li>SETSYS FASTREPLICATION
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx971" class="indexlink">DATASETRECOVERY</a>
</li>
<li><a href="e0z3m100.htm#idx979" class="indexlink">VOLUMEPAIRMESSAGES</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx1063" class="indexlink">shared file system</a>
</li>
<li><a href="e0z3m100.htm#idx158" class="indexlink">sharing restrictions, PDSE</a>
</li>
<li><a href="e0z3m100.htm#idx1336" class="indexlink">shortcut keys</a>
</li>
<li>SMA fields from the SMS storage group construct IGDSGD
<a href="e0z3m100.htm#idx397" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx931" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1204" class="indexlink">SMF 72.5 data collection</a>
</li>
<li>SMF 74.9 data collection
<a href="e0z3m100.htm#idx543" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1202" class="indexlink">(2)</a>
</li>
<li>SMF type 92 subtype 11 close records
<a href="e0z3m100.htm#idx638" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1308" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx76" class="indexlink">SMP/E, no migration actions for</a>
</li>
<li>SMP/E REPORT MISSINGFIX
<ul class="indexlist">
<li>FIXCAT
<a href="e0z3m100.htm#idx178" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx193" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>SMS control data sets, migrating
<a href="e0z3m100.htm#idx386" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx918" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx993" class="indexlink">SMS MVT chain rebuild (DFSMShsm), removal of patch preventing</a>
</li>
<li>SMS volume selection
<a href="e0z3m100.htm#idx426" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1003" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx804" class="indexlink">SNMP sysObjectID MIB object</a>
</li>
<li>software support of servers
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx204" class="indexlink">z10</a>
</li>
</ul>
</li>
<li>source control data set (SCDS), ensuring integrity of
<a href="e0z3m100.htm#idx390" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx922" class="indexlink">(2)</a>
</li>
<li>SSI 54
<ul class="indexlist">
<li>JES3 release format
<a href="e0z3m100.htm#idx507" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1135" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>SSI 82
<ul class="indexlist">
<li>JES3 release format
<a href="e0z3m100.htm#idx508" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1136" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>SSI 83
<ul class="indexlist">
<li>JES3 release format
<a href="e0z3m100.htm#idx509" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1137" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>SSI 85
<ul class="indexlist">
<li>authority
<a href="e0z3m100.htm#idx483" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1109" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>stand-alone dump, reassembling
<a href="e0z3m100.htm#idx271" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx701" class="indexlink">(2)</a>
</li>
<li>stand-alone dump data sets
<a href="e0z3m100.htm#idx255" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx673" class="indexlink">(2)</a>
</li>
<li>Stand-Alone Services, building core image of DFSMSdss
<a href="e0z3m100.htm#idx413" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx954" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx742" class="indexlink">start</a>
</li>
<li><a href="e0z3m100.htm#idx42" class="indexlink">steps for migration</a>
</li>
<li><a href="e0z3m100.htm#idx31" class="indexlink">steps to take, meaning of</a>
</li>
<li>sticky bit files
<a href="e0z3m100.htm#idx641" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx642" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx1311" class="indexlink">(3)</a>, <a href="e0z3m100.htm#idx1314" class="indexlink">(4)</a>
</li>
<li>storage
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx146" class="indexlink">backing virtual</a>
</li>
<li><a href="e0z3m100.htm#idx99" class="indexlink">evaluation with zSoftCap</a>
</li>
<li><a href="e0z3m100.htm#idx140" class="indexlink">setting virtual limits</a>
</li>
</ul>
</li>
<li>storage requirements
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx691" class="indexlink">Predictive Failure Analysis (PFA)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx136" class="indexlink">subsystems, reconnecting</a>
</li>
<li><a href="e0z3m100.htm#idx129" class="indexlink">SVC routines, migrating</a>
</li>
<li><a href="e0z3m100.htm#idx1313" class="indexlink">symbolic links for cron, mail, and uucp utilities</a>
</li>
<li>SYS1.IMAGELIB
<a href="e0z3m100.htm#idx409" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx943" class="indexlink">(2)</a>
</li>
<li>SYS1.PARMLIB
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx118" class="indexlink">used by IPCS</a>
</li>
<li><a href="e0z3m100.htm#idx120" class="indexlink">using shipped members of</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx122" class="indexlink">SYS1.PROCLIB, using shipped members of</a>
</li>
<li><a href="e0z3m100.htm#idx805" class="indexlink">sysObjectID MIB object, SNMP</a>
</li>
<li><a href="e0z3m100.htm#idx1062" class="indexlink">sysplex=filesys</a>
</li>
<li>sysplex migration actions
<ul class="indexlist">
<li>after first IPL
<a href="e0z3m100.htm#idx246" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx664" class="indexlink">(2)</a>
</li>
<li>before first IPL
<a href="e0z3m100.htm#idx239" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx657" class="indexlink">(2)</a>
</li>
<li>before installing
<a href="e0z3m100.htm#idx234" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx652" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>sysplex root from HFS to zFS, migrating
<a href="e0z3m100.htm#idx624" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1289" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1225" class="indexlink">sysplex-wide data on SDSF panels</a>
</li>
<li><a href="e0z3m100.htm#idx29" class="indexlink">system impacts, meaning of</a>
</li>
<li>System SSL, ensuring all RACF user IDs that start SSL applications in non-FIPS mode can access the CSFRNG resource of the CSFSERV class
<a href="e0z3m100.htm#idx374" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx906" class="indexlink">(2)</a>
</li>
<li>System SSL, ensuring ICSF is available when running System SSL in FIPS mode
<a href="e0z3m100.htm#idx372" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx904" class="indexlink">(2)</a>
</li>
<li>System SSL migration action
<a href="e0z3m100.htm#idx371" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx373" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx903" class="indexlink">(3)</a>, <a href="e0z3m100.htm#idx905" class="indexlink">(4)</a>
</li>
</ul>
<strong><a name="IDX1_54" href="#IDX0_54">T</a></strong>
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx25" class="indexlink">target system hardware requirements, meaning of</a>
</li>
<li><a href="e0z3m100.htm#idx26" class="indexlink">target system software requirements, meaning of</a>
</li>
<li>TCP/IP profile
<ul class="indexlist">
<li>IPSEC statement
<ul class="indexlist">
<li>DVIPSEC parameter
<a href="e0z3m100.htm#idx313" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx793" class="indexlink">(2)</a>
</li>
</ul>
</li>
</ul>
</li>
<li>TCP related configuration statements
<a href="e0z3m100.htm#idx349" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx863" class="indexlink">(2)</a>
</li>
<li>TCPIP
<ul class="indexlist">
<li>before the first IPL
<a href="e0z3m100.htm#idx333" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx847" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx10" class="indexlink">terminology used in this document</a>
</li>
<li><a href="e0z3m100.htm#idx77" class="indexlink">TIOC, no migration actions for</a>
</li>
<li><a href="e0z3m100.htm#idx697" class="indexlink">TIOT and XTIOT limits</a>
</li>
<li><a href="e0z3m100.htm#idx870" class="indexlink">TRACE command</a>
</li>
<li>TRACKDIRLOAD
<a href="e0z3m100.htm#idx295" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx755" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx821" class="indexlink">traffic monitoring</a>
</li>
<li><a href="e0z3m100.htm#idx78" class="indexlink">TSO/E, no migration actions for</a>
</li>
<li><a href="e0z3m100.htm#idx211" class="indexlink">TUNE(8) compiler option</a>
</li>
<li>TUNE=OLD, DFSORT
<a href="e0z3m100.htm#idx444" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1033" class="indexlink">(2)</a>
</li>
</ul>
<strong><a name="IDX1_55" href="#IDX0_55">U</a></strong>
<ul class="indexlist">
<li>Unicode Services
<a href="e0z3m100.htm#idx288" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx718" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx219" class="indexlink">unsupported devices, removing</a>
</li>
<li>Upgrade Java for Infoprint Server
<a href="e0z3m100.htm#idx477" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1078" class="indexlink">(2)</a>
</li>
<li>URL
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx230" class="indexlink">for CFCC levels and processors</a>
</li>
<li><a href="e0z3m100.htm#idx227" class="indexlink">for CFSizer tool</a>
</li>
<li><a href="e0z3m100.htm#idx207" class="indexlink">for Enhanced PSP Tool</a>
</li>
<li>for flashes
<a href="e0z3m100.htm#idx142" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx147" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx133" class="indexlink">for ISVs</a>
</li>
<li><a href="e0z3m100.htm#idx91" class="indexlink">for PSP buckets</a>
</li>
<li><a href="e0z3m100.htm#idx37" class="indexlink">for z/OS publications</a>
</li>
<li><a href="e0z3m100.htm#idx100" class="indexlink">for zSoftCap</a>
</li>
</ul>
</li>
<li>use of ICSF when running FIPS 140-2 mode applications
<a href="e0z3m100.htm#idx369" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx901" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx7" class="indexlink">use this document, how to</a>
</li>
<li>user exits
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx825" class="indexlink">FTCHKPWD</a>
</li>
<li><a href="e0z3m100.htm#idx1095" class="indexlink">IEFUSI</a>
</li>
<li>IGGPOST0
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx949" class="indexlink">update operator procedures for</a>
</li>
</ul>
</li>
<li>IGGPRE00
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx947" class="indexlink">update operator procedures for</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx1090" class="indexlink">Infoprint Server</a>
</li>
<li><a href="e0z3m100.htm#idx131" class="indexlink">migrating</a>
</li>
<li>SDSF
<a href="e0z3m100.htm#idx553" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1214" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx811" class="indexlink">User ID for the resolver, define</a>
</li>
<li>user interface
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1334" class="indexlink">ISPF</a>
</li>
<li><a href="e0z3m100.htm#idx1333" class="indexlink">TSO/E</a>
</li>
</ul>
</li>
<li>user modifications
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx126" class="indexlink">examining</a>
</li>
<li><a href="e0z3m100.htm#idx1157" class="indexlink">for Language Environment options</a>
</li>
</ul>
</li>
<li>usermods
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx128" class="indexlink">examining</a>
</li>
<li><a href="e0z3m100.htm#idx1159" class="indexlink">for Language Environment options</a>
</li>
</ul>
</li>
</ul>
<strong><a name="IDX1_56" href="#IDX0_56">V</a></strong>
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx868" class="indexlink">VIPARANGE definitions, review</a>
</li>
<li><a href="e0z3m100.htm#idx830" class="indexlink">VIPARANGE processing, understand</a>
</li>
<li>virtual storage
<a href="e0z3m100.htm#idx266" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx684" class="indexlink">(2)</a>
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx145" class="indexlink">backing</a>
</li>
<li><a href="e0z3m100.htm#idx139" class="indexlink">verifying limits</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx869" class="indexlink">VTAM internal trace</a>
</li>
<li><a href="e0z3m100.htm#idx871" class="indexlink">VTAM start list</a>
</li>
<li>VTOC track, DFSMShsm
<ul class="indexlist">
<li>default change for restore
<a href="e0z3m100.htm#idx428" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1015" class="indexlink">(2)</a>
</li>
</ul>
</li>
</ul>
<strong><a name="IDX1_57" href="#IDX0_57">W</a></strong>
<ul class="indexlist">
<li>WARNUND
<ul class="indexlist">
<li>IEASYSxx
<a href="e0z3m100.htm#idx268" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx686" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>web address
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx232" class="indexlink">for CFCC levels and processors</a>
</li>
<li><a href="e0z3m100.htm#idx229" class="indexlink">for CFSizer tool</a>
</li>
<li><a href="e0z3m100.htm#idx209" class="indexlink">for Enhanced PSP Tool</a>
</li>
<li>for flashes
<a href="e0z3m100.htm#idx144" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx149" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx135" class="indexlink">for ISVs</a>
</li>
<li><a href="e0z3m100.htm#idx93" class="indexlink">for PSP buckets</a>
</li>
<li><a href="e0z3m100.htm#idx39" class="indexlink">for z/OS publications</a>
</li>
<li><a href="e0z3m100.htm#idx102" class="indexlink">for zSoftCap</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx1224" class="indexlink">WebSphere MQ with SDSF</a>
</li>
<li><a href="e0z3m100.htm#idx23" class="indexlink">when change was introduced, meaning of</a>
</li>
<li><a href="e0z3m100.htm#idx1" class="indexlink">who should read this document</a>
</li>
<li><a href="e0z3m100.htm#idx813" class="indexlink">workload queueing function for EE traffic</a>
</li>
</ul>
<strong><a name="IDX1_58" href="#IDX0_58">X</a></strong>
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx106" class="indexlink">XCF groups</a>
</li>
<li>XCF/XES
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx726" class="indexlink">messages</a>
</li>
</ul>
</li>
<li>XL C/C++ migration actions
<ul class="indexlist">
<li>after first IPL
<a href="e0z3m100.htm#idx610" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1275" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx604" class="indexlink">before first IPL</a>
</li>
<li>before installing
<a href="e0z3m100.htm#idx600" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1271" class="indexlink">(2)</a>
</li>
</ul>
</li>
</ul>
<strong><a name="IDX1_5A" href="#IDX0_5A">Z</a></strong>
<ul class="indexlist">
<li>z/OS Font Collection, using IBM fonts
<a href="e0z3m100.htm#idx618" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1283" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx79" class="indexlink">z/OS IBM TDS, no migration actions for</a>
</li>
<li><a href="e0z3m100.htm#idx52" class="indexlink">z/OS Management Facility, IBM</a>
</li>
<li><a href="e0z3m100.htm#idx103" class="indexlink">z/OS root size</a>
</li>
<li><a href="e0z3m100.htm#idx80" class="indexlink">z/OS Security Level 3, no migration actions for</a>
</li>
<li>z/OS UNIX migration actions
<ul class="indexlist">
<li>after first IPL
<a href="e0z3m100.htm#idx643" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1315" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx1323" class="indexlink">(3)</a>
</li>
<li>before first IPL
<a href="e0z3m100.htm#idx632" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1302" class="indexlink">(2)</a>
</li>
<li>before installing
<a href="e0z3m100.htm#idx625" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1290" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>z/OS UNIX System Services Connection Scaling
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1301" class="indexlink">migration action</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx53" class="indexlink">z/OSMF</a>
<ul class="indexlist">
<li>IBM Configuration Assistant for z/OS Communications Server
<a href="e0z3m100.htm#idx309" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx789" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>z10 server
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx206" class="indexlink">coexistence requirements</a>
</li>
<li><a href="e0z3m100.htm#idx197" class="indexlink">compatibility changes</a>
</li>
<li><a href="e0z3m100.htm#idx198" class="indexlink">migrating to</a>
</li>
<li><a href="e0z3m100.htm#idx199" class="indexlink">software support features</a>
</li>
</ul>
</li>
<li>z11 mode
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx1122" class="indexlink">JES2</a>
</li>
</ul>
</li>
<li>z114 server
<ul class="indexlist">
<li>compatibility changes
<a href="e0z3m100.htm#idx173" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx188" class="indexlink">(2)</a>
</li>
<li>migrating to
<a href="e0z3m100.htm#idx174" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx176" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx189" class="indexlink">(3)</a>, <a href="e0z3m100.htm#idx191" class="indexlink">(4)</a>
</li>
</ul>
</li>
<li>z196 server
<ul class="indexlist">
<li>compatibility changes
<a href="e0z3m100.htm#idx167" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx182" class="indexlink">(2)</a>
</li>
<li>migrating to
<a href="e0z3m100.htm#idx169" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx171" class="indexlink">(2)</a>, <a href="e0z3m100.htm#idx184" class="indexlink">(3)</a>, <a href="e0z3m100.htm#idx186" class="indexlink">(4)</a>
</li>
</ul>
</li>
<li>zEC12 server
<ul class="indexlist">
<li><a href="e0z3m100.htm#idx162" class="indexlink">compatibility changes</a>
</li>
<li>migrating to
<a href="e0z3m100.htm#idx163" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx165" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>zEnterprise
<ul class="indexlist">
<li>migrating to
<a href="e0z3m100.htm#idx168" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx183" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx1061" class="indexlink">zFS</a>
</li>
<li>ZFS
<ul class="indexlist">
<li>RMF data gathering option
<a href="e0z3m100.htm#idx541" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1200" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li>zFS, migrating from HFS to
<a href="e0z3m100.htm#idx623" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1288" class="indexlink">(2)</a>
</li>
<li>zFS clone function
<a href="e0z3m100.htm#idx462" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1047" class="indexlink">(2)</a>
</li>
<li><a href="e0z3m100.htm#idx1056" class="indexlink">zFS cloning support</a>
</li>
<li><a href="e0z3m100.htm#idx1058" class="indexlink">zFS compatibility mode aggregates</a>
</li>
<li><a href="e0z3m100.htm#idx1057" class="indexlink">zFS multi-file system aggregates</a>
</li>
<li><a href="e0z3m100.htm#idx1052" class="indexlink">zFS storage requirements</a>
</li>
<li><a href="e0z3m100.htm#idx1054" class="indexlink">zfsspace utility</a>
</li>
<li>zlsof shell command
<ul class="indexlist">
<li>support added
<a href="e0z3m100.htm#idx631" class="indexlink">(1)</a>, <a href="e0z3m100.htm#idx1296" class="indexlink">(2)</a>
</li>
</ul>
</li>
<li><a href="e0z3m100.htm#idx96" class="indexlink">zSoftCap</a>
</li>
<li><a href="e0z3m100.htm#idx95" class="indexlink">zSoftware Migfration Capacity Planning Aid (zSoftCap)</a>
</li>
</ul>
<a id="Bot_Of_Page"></a>
</body>
</html>
